作業格式
- 課程名稱： 軟件工程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有稍微用過以外其他的都沒有上手過，所以就選擇了相對簡單的墨刀原型工具。另外，為了設計地稍微有特點，這個沒有專業學過畫畫的人翻牆去看了好多大佬的模板，但是設計的還是...。
當然，在此次作業中，也發現了原型的重要性，因為有原型，之后的實現才會更簡單，也能夠給客戶看一個相對完整的成果樣子。
周楊富
- 結對心得
第一次嘗試到《構建之法》中提到的結對編程這一概念。一開始以為只是兩個人把各自的任務分配好就能很好地完成這次作業。但是在原型設計時就發現其實沒有這么簡單，兩個人的工作並不是各自作為一個獨立的個體而存在的。它們之間存在互相依賴的關系。如果沒有很好地溝通，其實是不太好完成的。所以應該細化兩個人的任務，並及時進行溝通，共同地工作，才能使這一作業較快較好地完成。
- 項目總結
在閱讀了《構建之法》關於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 |