作业格式
- 课程名称： 软件工程1916|W（福州大学）
- 作业要求： 结对第一次—原型设计
- 结对学号： 221600308 | 221600340
- 作业目标：了解NABCD模型，学习分析用户需求和利用专业原型工作设计软件原型。
作业正文
NABCD模型
-
N （Need，需求）
-
帮助用户快速了解近几年顶会的热门领域和研究方向
-
**用户可给定论文列表 **
- 通过论文列表，爬取论文的题目、摘要、关键词、原文链接；
- 可对论文列表进行增删改操作(今年、近两年、近三年)；
-
对爬取的信息进行结构化处理，分析top10个热门领域或热门研究方向；
- 可对论文属性（oral、spotlight、poster）进行筛选及分析；
- 形成如关键词图谱之类直观的查看方式；
-
可进行论文检索，当用户输入论文编号、题目、关键词等基本信息，分析返回相关的paper、source code、homepage等信息；
-
对多年间、不同顶会的热词呈现热度走势对比（这里将范畴限定在计算机视觉的三大顶会CVPR、ICCV、ECCV内）。
-
可进行数据统计，例如每个国家录用文章的分析、每个学校录用文章的分析、哪个学校哪方面的研究方向比较强等。
-
以上的需求还是会有一些难理解，我们接着对需求进行了进一步地分析。
-
-
**A（Approach，方法） **
- 设计一个基于Web的平台实现用户的相关需求。
- 导入论文列表：
- 通过网页对话框形式手动输入论文列表信息。
- 选取具体顶会批量生成论文列表。
- 上传Excel文件批量导入论文信息生成论文列表。
- 已确定论文列表后，用户可通过网页端的一些交互按钮来实现对论文列表的批量或单独的增删改操作。
- 确定论文列表：
- 确定论文列表后，平台使用爬虫爬取相关论文的题目、摘要、关键词、原文链接，结构化处理并展示在平台主体部分。
- 对获取的论文根据热度进行排序。
- 用户可通过复选框根据年份以及属性筛选论文。
- 后台根据年份和顶会类型分析定制热词，并用matplotlib绘制出热词走势折线图供用户对比。
- 形成关键词图谱，展示在平台辅助区。
- 根据关键词分析排序出Top10个热门领域或热门研究方向。
- 论文检索：
- 用户在搜索栏输入论文的编号、题目、关键词等基本信息，分析并返回相关论文的Home page、Source code等信息。
- 用户根据提示点击Source code提示信息，展开Source code。
- 查询国家及学校组织论文情况
- 用户根据下拉框选取国家或学校组织论文，平台绘制出折线图、饼图、直方图等信息，供用户对比分析文章录用情况，以及强势研究方向等。
-
B（Benefit，好处）
- 界面简洁易上手。
- 以悬浮框的形式，方便用户同时查看不同分析材料。
- 左上角的功能区，简单直观。
- 悬浮框可拖拉，可用户自定义排列。
- 使用轻便的web端。
- 同一个账号多端登录可共享一个论文列表并实时保存。
- 不需要安装额外的软件。
- 高度自定义的论文列表。
- 可以通过选择具体顶会批量多次导入列表，也可以手动添加，接受按格式的Excel批量导入生成论文列表。
- 可以批量删除和进行筛选。可以将爬取的信息以Excel格式导出。
- 不过，由于一般用户论文方向基本确定，目前还未考虑用文件夹存储不同论文列表的方式。
- 界面简洁易上手。
-
C（Competitors，竞争）
- 优势：
- 目前国内还没有类似的开放平台，推广的好的话很容易被用户接受使用。
- 界面简洁，操作简单。
- 云存储。对经常往返实验室与宿舍的多端操作的用户友好。
- 劣势：
- 用户群体主要是在校师生。但对于大部分学生来说是“一次性的”，用户使用时长不过几个月。
- 数据集的获取：不一定能够获得知网的等网站的论文数据。
- 若知网等网站开发相似功能，则没有存在必要。但若要开发社区功能，做成论文相关问题的交流平台，工程复杂。
- 优势：
-
D（Delivery，推广）
- 线上推广：
- 借助论文助手等微信公众号平台，写软文进行推广。
- 与论文网站合作，提供平台入口。
- 线下推广：
- 师生交流和学长学姐推荐方式推广。
- 提升用户体验。
- 线上推广：
原型设计
使用工具：墨刀
原型预览： 顶会热词统计平台
- 阶段一：
- 根据需求拟定大概功能。
- 站在用户角度对操作步骤进行规划。
- 分工完成各模块的细化功能和大致草图。
- 阶段二：
- 共同交流各模块的功能。
- 进行调整。
- 确定界面草图。
- 阶段三：
- 通过原型工具设计原型。
- 讨论并进行原型调整。
-
原型截图
-
登录界面：
-
主界面：
-
偏暗的简单风格。
-
左上角为功能区。中间为论文列表和搜索栏。右侧为介绍。
-
点击搜索：
-
-
全部功能点满界面：
-
结对过程
由于我们在3月20日之前就要将之前参加的一个国赛的作品提交，所以在作业发布的当天晚上我们就已经开始明确分工。
流程如下：
- 线上对需求进行分析和讨论。
- 见面对原型进行讨论，拟定草图。
- 线上分别对自己的部分进行原型的设计和博客的撰写
- 将内容合并，发布。
结对照片
结对心得
熊宁畅
- 结对心得
之前一直对结对编程的效率存疑，因为去年有和学弟做一个比赛，在合代码的时候出了一些错，花了很多时间。所以我认为在做非大型项目的时候，自己一个人做的时间安排更加自由，也不需要多精力去沟通和磨合。但通过阅读《构建之法》和实践过程中，我了解到我先前的经历有种种不对的地方，例如没有很好的沟通，不少有想法出入的地方没有得到最优解。在对两人的分工和职责进行明确外，还需要实时的沟通和讨论，在有不同观点的时候进行客观的阐述，才能找到最好的解决方式。既能将结对编程的效率提高，又在一定程度上保证作品的质量。
- 项目总结
之前趁着刚开学没什么任务，将《构建之法》通读了一遍，看得并不算很细致。这次又返回去认真看了第三章和NABCD模型，再进行项目实践。不得不说这本书并不像其他的书脱离实际，而是能够在书中获得方法，将方法运用于实践，在实践中又记住书中的内容。
项目过程也并非顺利。
刚开始面对一大段的需求，有点不知道从哪里下手，见面后两个人对需求的理解也有偏差。不过好在经过一遍一遍地划重点总算是讨论出一个相对满意的需求和原型草图。
原型的设计主要是我负责，但由于没有相关的经验，除了RP有稍微用过以外其他的都没有上手过，所以就选择了相对简单的墨刀原型工具。另外，为了设计地稍微有特点，这个没有专业学过画画的人FQ去看了好多大佬的模板，但是设计的还是...。
当然，在此次作业中，也发现了原型的重要性，因为有原型，之后的实现才会更简单，也能够给客户看一个相对完整的成果样子。
周杨富
- 结对心得
第一次尝试到《构建之法》中提到的结对编程这一概念。一开始以为只是两个人把各自的任务分配好就能很好地完成这次作业。但是在原型设计时就发现其实没有这么简单，两个人的工作并不是各自作为一个独立的个体而存在的。它们之间存在互相依赖的关系。如果没有很好地沟通，其实是不太好完成的。所以应该细化两个人的任务，并及时进行沟通，共同地工作，才能使这一作业较快较好地完成。
- 项目总结
在阅读了《构建之法》关于NABCD的内容后开始做这次作业。一开始看书的时候觉得好像有点复杂，步骤繁多。但是真正上手之后才感受到这么做的好处，所以使得整个完成过程较为顺利
在原型设计时，一开始存在很多方案。一开始想尽量设计得华丽一点，但是考虑用户的使用体验，人机交互时，发现华丽并不意味着好用、实用。所以采用了现在的方案，使操作尽可能简单易用，使得用户能够较快上手。一开始在排布界面时，对于页面各组件的主次存在较大的疑惑，但是突然想到自己可以跳出开发者的思维，把自己当成一个用户来考虑，于是在试用多个类似的论文网站后，才决定出最后的方案。
效能分析及PSP
效能分析
目前还停留在原型设计阶段，如果是指《构建之法》2.2节指的效能分析的话，应该还不能确定哪些函数、语句会耗时最多。需要待之后进行补充。若是理解有出入，希望老师和助教指出，谢谢！
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
| Planning | 计划 | ||
| • Estimate | • 估计这个任务需要多少时间 | 570 | 590 |
| Development | 开发 | ||
| • Analysis | • 需求分析 (包括学习新技术) | 60 | 80 |
| • Design Spec | • 生成设计文档 | 60 | 40 |
| • Design Review | • 设计复审 | 30 | 40 |
| • Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 30 | 30 |
| • Design | • 具体设计 | 60 | 60 |
| • Coding | • 具体编码 | 300 | 280 |
| • Code Review | • 代码复审 | 30 | 30 |
| • Test | • 测试（自我测试，修改代码，提交修改） | 30 | 60 |
| Reporting | 报告 | ||
| • Test Repor | • 测试报告 | 60 | 100 |
| • Size Measurement | • 计算工作量 | 20 | 30 |
| • Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 30 | 45 |
| 合计 | 680 | 795 |