軟工實踐 第三次作業 結對作業一

Ⅰ.連結

結對同學部落格戳我

本次作業戳我

Ⅱ.設計說明

問題重述

• 使用者可給定論文清單
• 通過論文清單，爬取論文的題目、摘要、原文連結
• 可對論文清單進行增删改操作(今年、近兩年、近三年)
• 對爬取的資訊進行結構化處理，分析top10個熱門領域或熱門研究方向
• 可對論文屬性（oral、spotlight、poster）進行篩選及分析
• 形成如熱詞圖譜之類直覺的檢視方式
• 可進行論文檢索，當使用者輸入論文編号、題目、作者等基本資訊，分析傳回相關的paper、source code、homepage等資訊
• 可對多年間、不同頂會的熱詞呈現熱度走勢對比（這裡将範疇限定在計算機視覺的三大頂會CVPR、ICCV、ECCV内）
• 可進行資料統計，例如每個國家錄用文章的分析、每個學校錄用文章的分析、哪個學校哪方面的研究方向比較強等

針對以上文字，我們形成了最初步的思考，當時讨論的思維導圖（主要包括需求分析、使用場景、功能的确認以及相關背景知識）如下：

NABCD模型（競争性需求分析的架構）

• N(Need,需求)

  • 使用者類型

    本産品的使用者類型定位在：對于某個領域科研的前沿資訊有快速擷取需求的人群。顯然，我們就包含在本次結對項目的目标人群中。這樣，作為一個PM或者開發者，能夠以一個真正使用者的角色帶入産品的建構。更加了解在不同場景下，如何互動以及産品邏輯是最科學的。

  • 功能性需求

    功能需求的闡述大緻已在思維導圖以及問題描述中展現。解決的問題就是友善小櫻同學為代表的學生擷取論文并了解最新的研究趨勢，同時滿足對今年科研論文的一些統計（但個人認為并不是最核心的功能）。

  • 非功能性需求（服務品質需求）

    顯然，作為一個日後在學習中高頻使用的工具，應當滿足界面簡潔美觀、互動符合操作習慣和邏輯、并具有一定的人文關懷（本組設定了一個夜間模式用來保護視力）

  • 開發過程需求

    首先是确定産品要在哪個端使用，經過了解和詢問，大多數人閱讀paper都是在電腦端以及pad，于是本組決定，采用web端實作。

• A(Approach,做法)
  • 經讨論确定産品功能以web端呈現，既然核心實作是爬蟲，于是決定采用python開發，架構可能暫定以django開發。
• B(Benefit,好處)
  • 對于滿足使用者需求所使用的做法，開發者不單單要考慮到在功能特性上給使用者帶來的好處，還需要綜合考慮使用者使用自己産品所需要的使用成本，這樣的成本不隻是表面的産品花費，還有潛在的硬體要求、應用學習成本、遷移成本等等。
• C(Competitors,競争)

  • 傳統學術論文的搜尋彙總上，國内似乎基本都是使用微軟學術、谷歌學術、知網萬方之類的平台。對比于我們的産品，他們的優勢在于十分全面、煙波浩渺，然而阿喀琉斯之踵在于隻能單篇搜尋，也不能批量下載下傳，更沒有資料統計的功能。

    以微軟學術為例，查找某篇論文後，得到的隻是相關資訊和一些連結網站，擷取PDF的workflow十分冗長。

  • 學術界科研動态，在學術界，了解科研動态的主要平台（應該也是最主要）則為arxiv，但并沒有各個領域的細化等。
  • 相關機構及自媒體，随着相關領域的火爆，也有許多機構和自媒體會在CSDN、知乎等平台分享業内最新動态，但問題在于所獲得的資訊并不是第一手的，很容易出現夾帶私貨的現象。
  • 個人開發者，可能也有相關的個人開發者做了類似的産品，具體的分析則需要到GitHub上進一步了解分析。

  

• D(Delivery,推廣)
  • 如果實作的話，在小範圍内（課堂）進行講解和宣傳。當然這已經是後話了。

功能定位&原型展示

工作流圖

界面原型圖

LINKS-預覽模式

• 該模式下可預覽本地論文的摘要、作者、組織、類别等資訊

• 在LINKS模式下可點選右上角IMPORT按鍵進行論文清單拖拽上傳

• 上傳成功後會彈出成功界面

FOCUS-閱讀模式

• 該模式下可完整閱讀論文，同時右下角設有回到頂部以及下載下傳全文按鈕

• 在FOCUS模式下可點選右上角IMPORT按鍵進行論文清單拖拽上傳

TRENDS-熱點模式

• 該模式下可根據會議類型以及年份生成對應的焦點詞熱度表

• 在TRENDS模式下可點選右上角IMPORT按鍵進行論文清單拖拽上傳

IMPORT-上傳功能鍵

• 在任意模式下均可點選右上角IMPORT按鍵進行論文清單拖拽上傳，上傳成功後會彈出成功界面，再次點選将進入LIST頁面

LIST-清單功能鍵

• 在任何模式下均可點選右上角LIST功能鍵可以進入論文清單頁面，在論文清單頁面可以通過上方的搜尋框和篩選欄以及右上角的三個小功能鍵和右側勾選框，對論文清單進行批量的下載下傳、查詢、添加處理

ANALYSE-分析功能鍵

• 在任何模式下均可點選右上角ANALYSE鍵進入分析頁面，在分析頁面下，可以根據會議的類型、年份、參與國家以及參與組織生成論文釋出數量的扇形圖供使用者參考

NIGHT-夜間模式

• 單擊右上角夜間模式按鈕切換螢幕色調（此處以LINK的夜間模式為例）

背景知識

• 關于ORAL、SPOTLITHS、POSTER的差別

  本組閱讀了王源分享的連結:ICCV小記

  根據裡面内容，大緻明白了三者的差別，重要程度從oral>spotlights>poster,所謂物以稀為貴，三者的比例也逐次遞減。

• 還有就是各大會議的一些情況以及展開形式也在本次有所了解了，如有精力，再做分享。
• 對于論文作者以及機構的統計，由于浏覽了論文清單，發現有的實在很長，于是決定隻統計一作和通訊作者。此點不知是否合理，還有待讨論。

特色功能

• LINKS視圖

  閱讀文獻，就是在了解作者所作的研究以及思路，而參考文獻是一項重要的環節。而目前我們閱讀文獻時，總還要花大量的精力去搜尋相關參考文獻，而LINKS視圖則為使用者呈現所閱讀文章的參考文獻，并給出概覽。極大地友善了使用者。

  至于為什麼要單獨放在一個界面，不僅僅是為了美觀考慮，也是要讓使用者能專注地閱讀文獻。

• 夜間模式

  我們躬耕于黑暗，卻不放棄光明。代碼冰冷，亦能帶來溫情。

  身為計算機的學生，無數日夜躬耕于黑暗，也因ddl的逼迫，也因享受夜晚工作的甯靜。但刺眼的白色界面在吞噬着我們的眼睛，是以，我們貼心地設定了夜間模式。

Ⅲ.結對過程

讨論與建構

• 閉門造車 出門合轍

  既然是兩個人的合作，非常容易出現“一拍即合”情況，讨論若無思考的基礎，兩個人的腦子往往會變成一個人的腦子。是以本組先是不經過溝通，經過各人的思考，帶來自己的想法和解決方案，再通過讨論合并顯然會使産品的可靠性大大增加。

• 頭腦風暴

  好玩的功能往往是腦洞出來的，是以在讨論中，要充分采用頭腦風暴的方式。

  而前面的出門合轍則更需要頭腦風暴的幫助，兩個人的想法孰優孰劣？能不能合并？能不能兼取？

• 換位思考 場景帶入

  若說頭腦風暴是發散，則這個過程是收斂。

  頭腦風暴的産物，要經過場景帶入的考驗，産品才會更符合邏輯。才不會成為人家口中的腦殘設計。

PSP表格

PSP3.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	30	60
· Estimate	· 估計這個任務需要多少時間
Development	開發	410	455
· Analysis	· 需求分析 (包括原型模型工具選擇)	120
· Design Spec	· 生成設計文檔
· Design Review	· 設計複審		20
· Design Standard	· 确定設計标準
· Design	· 具體設計		240
· Project Review	· 項目複審		50
· Test	· 測試（使用者測試溝通）		45
Reporting	報告	75	100
· Test Report	· 測試報告（總結設計需求變更）
· Size Measurement	· 計算工作量	15	10
· Postmortem & Process Improvement Plan	· 事後總結, 并提出過程改進計劃
總計	515	615

困難與解決

結對的意義在于為接下來的teamwork打基礎。

從工作流上來講，怎麼去分割任務再配置設定出去，某項事物需要協作該怎麼進行，如何讓對方了解你的想法，溝通該怎麼去有效溝通，盡管我們已經有一定的經曆，但在運用專業知識解決問題并進行合作的情況并不多見，是以接下來的實踐還能學到很多。

多人協作方面的文檔，我組強烈推薦堅果雲。

學習進度條

第N周	新增代碼（行）	累計代碼（行）	本周學習耗時（小時）	累計學習耗時（小時）	重要成長
1	12		學習建構之法的前面部分内容
2	200		21	33	學習需求開發模型，鞏固c++程式設計基礎
3		400	22	55	學習原型工具墨刀，鞏固c++