作業描述
| 作業描述 | 連結 |
|---|---|
| 這個作業屬於哪個課程 | https://edu.cnblogs.com/campus/fzu/SoftwareEngineering1916W |
| 這個作業要求在哪裡 | https://edu.cnblogs.com/campus/fzu/SoftwareEngineering1916W/homework/2642 |
| 結對學號 | 221600131、221600439 |
| 作業目標 | 瞭解NABCD模型，學習分析使用者需求，利用相關軟體設計原型 |
結對過程
快速組好了隊，之後就是進行需求分析。參考《構建之法》第八章第8.1節《軟體需求》指出的步驟，我們分析如下：
- 需求捕捉：題目已經代我們完成了這個步驟。
- 分析和定義需求：這個是我們最核心的步驟，明確這個需求究竟是為了什麼而出現的。
我們分析認為，我們的產品面向的人員是高校內相關領域的師生，根據需求得出的使用者畫像如下：
- 使用者是高校從事科研的師生。
- 提出需求的使用者關注計算機視覺， CVPR、ICCV、ECCV 等會議是該領域的頂會。
而目的則是為這些人提供論文檢索與資料分析，方便他們查詢到相關論文。我們整理需求得出以下核心需求：
- 使用者需要快速下載/查詢一系列論文。
- 使用者需要各類關鍵詞對比等資料分析。
我們參考知網等論文查詢網站，寫下了基本需求。但知網等作為通用型查詢網站，需要滿足所有人的需求，勢必只能提取出公共部分。類似什麼論文推薦都屬於這一部分。但我們不同的是，我們的客戶有指向性。我們需求的初期目標針對的是計算機視覺領域，這個領域和其他領域比有以下不同：
- 相當一部分論文在GitHub上開源了原始碼，供大家Clone。GitHub是一個程式設計師社交平臺，可以看出一個專案的熱度。
- 計算機視覺有一些公共資料集供大家benchmark，涉及某個子領域的論文一般都會寫明自己benchmark的資料。
因此，我們找到了這個專案的需求和創新點，接下來的事情就是結隊寫需求+墨刀原型了。
NABCD模型
Needs
使用者的原始需求
- 使用者可給定論文列表
- 通過論文列表，爬取論文的題目、摘要、關鍵詞、原文連結；
- 可對論文列表進行增刪改操作(今年、近兩年、近三年)；
- 對爬取的資訊進行結構化處理，分析top10個熱門領域或熱門研究方向；
- 可對論文屬性（oral、spotlight、poster）進行篩選及分析；
- 形成如關鍵詞圖譜之類直觀的檢視方式；
- 可進行論文檢索，當使用者輸入論文編號、題目、關鍵詞等基本資訊，分析返回相關的paper、source code、homepage等資訊；
- 可對多年間、不同頂會的熱詞呈現熱度走勢對比（這裡將範疇限定在計算機視覺的三大頂會CVPR、ICCV、ECCV內）。
- 可進行資料統計，例如每個國家錄用文章的分析、每個學校錄用文章的分析、哪個學校哪方面的研究方向比較強等。
分析
《構建之法》第八章，8.1節《軟體需求》指出，我們需要“對從各個方面獲取的需求進行規整，定義需求的內涵”。我們認為，目前佈置的這個需求，只是一個給高校內相關領域成員使用的論文檢索與資料分析平臺，一切都圍繞著這個點進行設計與開發。因此，我們不應該做太多不相關需求。既要做加法，也要做減法。
為此，我們整理需求如下：
使用者
系統支援多使用者登入。
使用者新增論文
- 使用者給定列表。該列表可能是一組論文標題，也可能是會議名稱。
- 當使用者輸入為一組論文標題時，先進行內部查詢。如該論文未被入庫，嘗試從網際網路查詢到相應論文URL。
- 當使用者輸入為會議名稱時，嘗試抓取該會議所有論文標題，並從標題查詢對應URL。
- 分析指定列表，列入論文爬取待處理佇列。 使用者可隨時對待處理佇列進行修改。
- 論文爬取：
- 從待處理佇列中取出相應URL，獲得論文的題目、摘要、關鍵詞、原文連結、領域、研究方向、原始碼、資料集等，對爬取的資訊進行結構化處理，並存入公用論文庫。
- 對公用論文庫內的論文，定期更新其下載量及被引量（如果被爬取方可提供的話）。當其被其他論文引用時，一併收錄引用其的論文。
使用者個人頁面
- 顯示使用者關注的領域、作者、機構的最新論文。
- 顯示使用者關注的論文的最新動向（如被引列表）。
- 為使用者個性化推薦最新論文。這部份暫時預留，不做實現。
檢索論文
- 使用者可依據以下維度檢索論文：論文編號、論文題目（模糊）、關鍵詞（模糊）、發表時間（年份及月份區間）、屬性（oral、spotlight、poster）、領域、作者、單位、研究方向、會議、對當前使用者是否可見。
- 檢索結果列表需滿足：
- 檢索摘要包括論文題目、屬性、作者、單位、會議、下載量、被引量。
- 可按照指定列排序。
- 點選進入論文詳細頁面。
- 提供論文批量管理：
- 允許有刪除許可權的使用者（如管理員）刪除本篇論文。
- 允許當前使用者標記本論文為當前使用者永不可見。
- 允許當前使用者設定是否關注本篇論文。
- 詳細頁面需滿足：
- 點選“關鍵詞”等可被資料分析的範圍，進入資料分析頁面。範圍見資料分析一節。
- 顯示論文題目、屬性、作者、單位、會議、下載量、被引量、摘要、關鍵詞、引用列表、被引列表、可能相關論文列表。
- 顯示原始碼下載連結、作者個人主頁（如果有的話）。
- 可直接下載論文，或跳轉到論文所在雜誌頁面/會議頁面，或跳轉到索引頁面。
- 提供論文管理功能，即：刪除、是否可見、是否關注。
資料分析
資料分析指標對論文庫整體的分析，“當前使用者不可見”的選項對其無效。
總體監控
- 顯示最近抓取的新論文列表。
- 顯示最近關注最多的新論文列表，計算維度包括：
- 若該論文在GitHub上有提供原始碼，以GitHub Star和Issue的數量為其中之一計算維度。
- Twitter等社交媒體的提及數量。
- 被引用次數。
關鍵詞
列表
- 依據關鍵詞，顯示 Top 10 熱門領域或熱門研究方向。同時繪製關鍵詞雲圖，以便直觀顯示出哪些關鍵詞最引人注目。
- 顯示以論文數量倒序排序的關鍵詞排行。
- 展示多年間不同頂會的熱詞對比。（頂會：暫只考慮CVPR、ICCV、ECCV）
- 每個頂會各一個柱狀圖。柱狀圖取當年Top X關鍵詞，每個關鍵詞為一組，每組內含三個柱，分別代表這三年的該詞論文數量。
詳細
- 允許使用者關注或取消關注。
- 顯示熱度趨勢（按月？按年？待細化）。
- 顯示該領域論文，可通過排序獲得：
- 該領域最新論文
- 顯示該領域指定時間（預設為1年內）被引最多論文。
- 該領域最近最熱論文
- 顯示折線圖：該關鍵詞每年的熱度。
- 資料集對比。
資料集對比
每一個關鍵詞對應的資料集均不同，可以針對每一個關鍵詞設定不同的資料集，由爬蟲對論文內提到的資料集進行分析，提取出該資料集的對比資料。 該頁面需要：
- 準確率進展趨勢。
- 領域排行榜。
國家
國家資料過於泛，對於單個領域的研究幾乎是沒什麼作用的。因此國家資料應當依託於關鍵詞，在關鍵詞之上對不同國家進行對比。
列表
- 顯示以論文數量倒序排序的國家排行。
- 展示TOP X國家的歷年論文發表數量，以折線圖顯示。
- 展示不同國家論文發表比例，以餅圖顯示。
詳細
- 顯示以論文數量倒序排序的機構排行。
- 顯示國家論文，可排序獲得：
- 該國家在該領域的最新論文。
- 顯示該國家指定時間（預設為1年內）被引最多論文。
- 顯示折線圖：該國家每年（月？）在該關鍵詞發表論文的數量，即熱度趨勢。
機構
基本同國家。
Approachs
基於 Web 開發技術，前端採用 React + ant.design。後端使用 MySQL 資料庫，幷包括以下幾個部分：
- 後端API：Java，配合Spring Boot + MyBatis。
- 搜尋：ElasticSearch。
- 服務間通訊：Kafka。
- 爬蟲：從Kafka接收佇列並爬取資料，爬取後儲存入物件儲存並將結構化資料入庫。
論文儲存：上雲使用阿里雲OSS，自建使用Minio（Amazon S3 API 相容）。
目前由於資料分析需求不復雜，暫不需要專用資料處理端並儲存結果，直接由大後端統一處理即可。以上架構可方便地上雲或自建。
Benefits
使用者
- 貼近學術前沿，相對通用性查詢網站來說會更貼合相關方向的課題組。
- 提供個性化論文推薦，可使使用者快速獲知所在領域最新動態。
- 可自動分析不同論文對相同公共資料集的準確性並排序，快速篩選效果最好的一系列論文。
開發機構
- 自主智慧財產權，避免受制於人。
- 對於開發機構自身，可通過自己定製化開發完成自己的特殊需求。
- 自動化爬取最新資訊，避免手動下載與分享帶來的繁瑣。
- 鍛鍊相關課題組學生開發與工程水平。
Competitors
優勢
優勢和“B”似乎意義相近。
劣勢
- 爬取速度。類似知網、萬方等資料庫均可接觸到一手資源，本專案只能爬取二手資訊，時效性差。
- 資料量。需要相當長一段時間可能才能爬取數目足夠的論文。考慮到即使機構訂閱了相關資料庫，對方也禁止使用爬蟲下載，這違反了使用協議，且對方也有相關反制措施，必須控制爬蟲速度。
- 穩定性。專案初期穩定性相對差。
- 搜尋。自己做的搜尋效果遠比不上對方專業搜尋，這需要之後進一步維護。
Delivery
對外開放部分只能開放索引查詢及資料分析。考慮到，相當一部分論文不處於Public Domain，下載與儲存部分涉嫌侵犯版權，且CDN流量相對貴，初期暫不允許校外機構下載論文。
我們不認為盲目面向非特定目標人群推廣存在意義，推廣應當“快、準、狠”。由於學術圈本身較小，我們認為，應當在初期交由學生及相關導師，請其使用。由導師以及學生私下交際圈口口相傳並提出進一步改進需求，逐漸完善程式本身的同時根據使用者使用情況來制定下一步推廣策略。
協作工具
- 關於Markdown文件，我們採用 https://hackmd.io 進行協作。
- 關於原型開發工具，我們採用墨刀。
原型模型
《構建之法》第七章，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
是否解決
已解決。