課程名稱：軟體工程實踐
作業要求：結對第一次—原型設計（文獻摘要熱詞統計）
結對學號：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 |