軟工實踐第二次做業（結對第一次做業）

做業描述

做業描述	連接
這個做業屬於哪一個課程	https://edu.cnblogs.com/campus/fzu/SoftwareEngineering1916W
這個做業要求在哪裏	https://edu.cnblogs.com/campus/fzu/SoftwareEngineering1916W/homework/2642
結對學號	22160013一、221600439
做業目標	瞭解NABCD模型，學習分析用戶需求，利用相關軟件設計原型
PDF	PDF

結對過程

快速組好了隊，以後就是進行需求分析。參考《構建之法》第八章第8.1節《軟件需求》指出的步驟，咱們分析以下：

1. 需求捕捉：題目已經代咱們完成了這個步驟。
2. 分析和定義需求：這個是咱們最核心的步驟，明確這個需求到底是爲了什麼而出現的。

咱們分析認爲，咱們的產品面向的人員是高校內相關領域的師生，根據需求得出的用戶畫像以下：

1. 用戶是高校從事科研的師生。
2. 提出需求的用戶關注計算機視覺， CVPR、ICCV、ECCV 等會議是該領域的頂會。

而目的則是爲這些人提供論文檢索與數據分析，方便他們查找到相關論文。咱們整理需求得出如下核心需求：

1. 用戶須要快速下載/查詢一系列論文。
2. 用戶須要各種關鍵詞對比等數據分析。

咱們參考知網等論文查詢網站，寫下了基本需求。但知網等做爲通用型查詢網站，須要知足全部人的需求，勢必只能提取出公共部分。相似什麼論文推薦都屬於這一部分。但咱們不一樣的是，咱們的客戶有指向性。咱們需求的初期目標針對的是計算機視覺領域，這個領域和其餘領域比有如下不一樣：

1. 至關一部分論文在GitHub上開源了源碼，供你們Clone。GitHub是一個程序員社交平臺，能夠看出一個項目的熱度。
2. 計算機視覺有一些公共數據集供你們benchmark，涉及某個子領域的論文通常都會寫明本身benchmark的數據。

所以，咱們找到了這個項目的需求和創新點，接下來的事情就是結隊寫需求+墨刀原型了。

NABCD模型

Needs

用戶的原始需求

• 用戶可給定論文列表
  • 經過論文列表，爬取論文的題目、摘要、關鍵詞、原文連接；
  • 可對論文列表進行增刪改操做(今年、近兩年、近三年)；
• 對爬取的信息進行結構化處理，分析top10個熱門領域或熱門研究方向；
  • 可對論文屬性（oral、spotlight、poster）進行篩選及分析；
  • 造成如關鍵詞圖譜之類直觀的查看方式；
• 可進行論文檢索，當用戶輸入論文編號、題目、關鍵詞等基本信息，分析返回相關的paper、source code、homepage等信息；
• 可對多年間、不一樣頂會的熱詞呈現熱度走勢對比（這裏將範疇限定在計算機視覺的三大頂會CVPR、ICCV、ECCV內）。
• 可進行數據統計，例如每一個國家錄用文章的分析、每一個學校錄用文章的分析、哪一個學校哪方面的研究方向比較強等。

分析

《構建之法》第八章，8.1節《軟件需求》指出，咱們須要「對從各個方面獲取的需求進行規整，定義需求的內涵」。咱們認爲，目前佈置的這個需求，只是一個給高校內相關領域成員使用的論文檢索與數據分析平臺，一切都圍繞着這個點進行設計與開發。所以，咱們不該該作太多不相關需求。既要作加法，也要作減法。

爲此，咱們整理需求以下：

用戶

系統支持多用戶登陸。

用戶新增論文

1. 用戶給定列表。該列表多是一組論文標題，也多是會議名稱。
   1. 當用戶輸入爲一組論文標題時，先進行內部查詢。如該論文未被入庫，嘗試從互聯網查找到相應論文URL。
   2. 當用戶輸入爲會議名稱時，嘗試抓取該會議全部論文標題，並從標題查找對應URL。
   3. 分析指定列表，列入論文爬取待處理隊列。 用戶可隨時對待處理隊列進行修改。
2. 論文爬取：
   1. 從待處理隊列中取出相應URL，得到論文的題目、摘要、關鍵詞、原文連接、領域、研究方向、源碼、數據集等，對爬取的信息進行結構化處理，並存入公用論文庫。
   2. 對公用論文庫內的論文，按期更新其下載量及被引量（若是被爬取方可提供的話）。當其被其餘論文引用時，一併收錄引用其的論文。

用戶我的頁面

1. 顯示用戶關注的領域、做者、機構的最新論文。
2. 顯示用戶關注的論文的最新動向（如被引列表）。
3. 爲用戶個性化推薦最新論文。這部份暫時預留，不作實現。

檢索論文

1. 用戶可依據如下維度檢索論文：論文編號、論文題目（模糊）、關鍵詞（模糊）、發表時間（年份及月份區間）、屬性（oral、spotlight、poster）、領域、做者、單位、研究方向、會議、對當前用戶是否可見。
2. 檢索結果列表需知足：
   1. 檢索摘要包括論文題目、屬性、做者、單位、會議、下載量、被引量。
   2. 可按照指定列排序。
   3. 點擊進入論文詳細頁面。
   4. 提供論文批量管理：
      1. 容許有刪除權限的用戶（如管理員）刪除本篇論文。
      2. 容許當前用戶標記本論文爲當前用戶永不可見。
      3. 容許當前用戶設置是否關注本篇論文。
         
3. 詳細頁面需知足：
   1. 點擊「關鍵詞」等可被數據分析的範圍，進入數據分析頁面。範圍見數據分析一節。
   2. 顯示論文題目、屬性、做者、單位、會議、下載量、被引量、摘要、關鍵詞、引用列表、被引列表、可能相關論文列表。
   3. 顯示源碼下載連接、做者我的主頁（若是有的話）。
   4. 可直接下載論文，或跳轉到論文所在雜誌頁面/會議頁面，或跳轉到索引頁面。
   5. 提供論文管理功能，即：刪除、是否可見、是否關注。

數據分析

數據分析指針對論文庫總體的分析，「當前用戶不可見」的選項對其無效。

整體監控

1. 顯示最近抓取的新論文列表。
2. 顯示最近關注最多的新論文列表，計算維度包括：
   1. 若該論文在GitHub上有提供源碼，以GitHub Star和Issue的數量爲其中之一計算維度。
   2. Twitter等社交媒體的說起數量。
   3. 被引用次數。

關鍵詞

列表

1. 依據關鍵詞，顯示 Top 10 熱門領域或熱門研究方向。同時繪製關鍵詞雲圖，以便直觀顯示出哪些關鍵詞最引人注目。
2. 顯示以論文數量倒序排序的關鍵詞排行。
3. 展現多年間不一樣頂會的熱詞對比。（頂會：暫只考慮CVPR、ICCV、ECCV）
   1. 每一個頂會各一個柱狀圖。柱狀圖取當年Top X關鍵詞，每一個關鍵詞爲一組，每組內含三個柱，分別表明這三年的該詞論文數量。

詳細

1. 容許用戶關注或取消關注。
2. 顯示熱度趨勢（按月？按年？待細化）。
3. 顯示該領域論文，可經過排序得到：
   1. 該領域最新論文
   2. 顯示該領域指定時間（默認爲1年內）被引最多論文。
   3. 該領域最近最熱論文
4. 顯示折線圖：該關鍵詞每一年的熱度。
5. 數據集對比。

數據集對比

每個關鍵詞對應的數據集均不一樣，能夠針對每個關鍵詞設置不一樣的數據集，由爬蟲對論文內提到的數據集進行分析，提取出該數據集的對比數據。 該頁面須要：

1. 準確率進展趨勢。
2. 領域排行榜。

國家

國家數據過於泛，對於單個領域的研究幾乎是沒什麼做用的。所以國家數據應當依託於關鍵詞，在關鍵詞之上對不一樣國家進行對比。

列表

1. 顯示以論文數量倒序排序的國家排行。
2. 展現TOP X國家的歷年論文發表數量，以折線圖顯示。
3. 展現不一樣國家論文發表比例，以餅圖顯示。

詳細

1. 顯示以論文數量倒序排序的機構排行。
2. 顯示國家論文，可排序得到：
   1. 該國家在該領域的最新論文。
   2. 顯示該國家指定時間（默認爲1年內）被引最多論文。
3. 顯示折線圖：該國家每一年（月？）在該關鍵詞發表論文的數量，即熱度趨勢。

機構

基本同國家。

Approachs

基於 Web 開發技術，前端採用 React + ant.design。後端使用 MySQL 數據庫，幷包括如下幾個部分：

1. 後端API：Java，配合Spring Boot + MyBatis。
2. 搜索：ElasticSearch。
3. 服務間通訊：Kafka。
4. 爬蟲：從Kafka接收隊列並爬取數據，爬取後存儲入對象存儲並將結構化數據入庫。

5. 論文存儲：上雲使用阿里雲OSS，自建使用Minio（Amazon S3 API 兼容）。

   目前因爲數據分析需求不復雜，暫不須要專用數據處理端並保存結果，直接由大後端統一處理便可。以上架構可方便地上雲或自建。

Benefits

用戶

1. 貼近學術前沿，相對通用性查詢網站來講會更貼合相關方向的課題組。
2. 提供個性化論文推薦，可以使用戶快速獲知所在領域最新動態。
3. 可自動分析不一樣論文對相同公共數據集的準確性並排序，快速篩選效果最好的一系列論文。

開發機構

1. 自主知識產權，避免受制於人。
   1. 對於開發機構自身，可經過本身定製化開發完成本身的特殊需求。
2. 自動化爬取最新信息，避免手動下載與分享帶來的繁瑣。
3. 鍛鍊相關課題組學生開發與工程水平。

Competitors

優點

優點和「B」彷佛意義相近。

劣勢

1. 爬取速度。相似知網、萬方等數據庫都可接觸到一手資源，本項目只能爬取二手資訊，時效性差。
2. 數據量。須要至關長一段時間可能才能爬取數目足夠的論文。考慮到即便機構訂閱了相關數據庫，對方也禁止使用爬蟲下載，這違反了使用協議，且對方也有相關反制措施，必須控制爬蟲速度。
3. 穩定性。項目初期穩定性相對差。
4. 搜索。本身作的搜索效果遠比不上對方專業搜索，這須要以後進一步維護。

Delivery

對外開放部分只能開放索引查詢及數據分析。考慮到，至關一部分論文不處於Public Domain，下載與存儲部分涉嫌侵犯版權，且CDN流量相對貴，初期暫不容許校外機構下載論文。
咱們不認爲盲目面向非特定目標人羣推廣存在乎義，推廣應當「快、準、狠」。因爲學術圈自己較小，咱們認爲，應當在初期交由學生及相關導師，請其使用。由導師以及學生私下交際圈口口相傳並提出進一步改進需求，逐漸完善程序自己的同時根據用戶使用狀況來制定下一步推廣策略。

協做工具

1. 關於Markdown文檔，咱們採用 https://hackmd.io 進行協做。
2. 關於原型開發工具，咱們採用墨刀。

原型模型

《構建之法》第七章，7.2.7節《投資質量》指出，「在作快速原型的過程當中，有些部分能夠作得粗糙一點。」。咱們認爲，原型只是爲了指出這個頁面有哪些功能，並非具體到去作某個頁面設計。何況，咱們的初步需求仍是有至關大的被推翻的可能性。所以，咱們作了如下較爲粗糙的原型。

論文列表

待爬取隊列

高級檢索

基本參考知網設計。

檢索結果

添加論文

論文詳細頁面

數據分析

整體監控

關鍵詞

關鍵詞詳細信息

領域最新方法

國家分析

國家詳細信息

論文推薦

結對照片

PSP表格

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃
- Estimate	估計這個任務須要多少時間	30	10
Development	開發
- Analysis	需求分析 (包括學習新技術)	180（學習新技術被計入具體編碼部分）	240
- Design Spec	生成設計文檔	360	240
- Design Review	設計複審	240	120
- Coding Standard	代碼規範 (爲目前的開發制定合適的規範)	1
- Design	具體設計	1440
- Coding	具體編碼	13440	項目未開始
- Code Review	代碼複審	貫穿代碼開發過程，不做爲單獨流程	0
- Test	測試（自我測試，修改代碼，提交修改）	貫穿代碼開發過程，不做爲單獨流程	0
Reporting	報告
- Test Report	測試報告	240	0
- Size Measurement	計算工做量	120
- Postmortem & Process Improvement Plan	過後總結, 並提出過程改進計劃	240
	合計	16051

遇到的困難及解決方法

困難1

困難描述

需求設計後難以取捨。

解決嘗試

討論。

是否解決

已解決。

有何收穫

需求設計不能一口吃成個大胖子，必須緊扣核心需求，圍繞核心需求進行擴展。

困難2

困難描述

博客園的編輯器太難用。

解決嘗試

使用Hackmd

是否解決

已解決。