Ⅰ.鏈接

結對同學博客
作業鏈接

Ⅱ.設計說明

問題重述

• 用戶可給定論文列表
• 通過論文列表，爬取論文的題目、摘要、原文鏈接
• 可對論文列表進行增刪改操作(今年、近兩年、近三年)
• 對爬取的信息進行結構化處理，分析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,推廣)

  • 如果實現的話，在小範圍內（課堂）進行講解和宣傳。當然這已經是後話了。

功能定位&原型展示

工作流圖

圖片經過原型軟件壓縮，欲查看高品質原圖請移步
原型鏈接

背景知識

• 關於ORAL、SPOTLITHS、POSTER的區別

  本組閱讀了王源分享的鏈接:ICCV小記
  根據裏面內容，大致明白了三者的區別，重要程度從oral>spotlights>poster,所謂物以稀為貴，三者的比例也逐次遞減。

• 還有就是各大會議的一些情況以及展開形式也在本次有所了解了，如有精力，再做分享。

• 對於論文作者以及機構的統計，由於瀏覽了論文列表，發現有的實在很長，於是決定只統計一作和通訊作者。此點不知是否合理，還有待討論。

特色功能

• LINKS視圖

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

  至於為什麽要單獨放在一個界面，不僅僅是為了美觀考慮，也是要讓用戶能專註地閱讀文獻。

• 夜間模式

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

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

Ⅲ.結對過程

討論與構建

• 閉門造車 出門合轍

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

• 頭腦風暴

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

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

• 換位思考 場景帶入

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

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

PSP表格

困難與解決

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

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

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

學習進度條

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