1. 程式人生 > >軟工之 NABCD 模型分析及 Web of Paper 原型設計結對作業

軟工之 NABCD 模型分析及 Web of Paper 原型設計結對作業

思考 軟件 筆記 行數據 自己的 操作 制作 發表 讀書

目錄

  • 寫在前面
  • NABCD 模型
    • N —— Need,需求
    • A —— Approach,方法
    • B —— Benefits,好處
    • C —— Compettors,競爭
      • 優勢
      • 劣勢
    • D —— Delivery, 推廣
  • 閱讀《構建之法》及成果
  • 結對過程
  • 遇到的困難及解決方法
  • 原型實現
  • PSP表格
  • 學習進度條
  • 總結
  • 體會

寫在前面

  • 本次作業:https://edu.cnblogs.com/campus/fzu/Grade2016SE/homework/2107
  • 隊友作業地址
  • pdf 文件地址
  • 結對成員:031602543 周政演、031602507 陳俞辛
  • 原型設計工具:墨刀
  • 使用該工具的原因:
    • 功能模塊化,能選擇頁面切換特效及主題
    • 操作方式也相對簡便,大部分操作都可通過拖拽來完成
    • 實驗室學長曾用墨刀演示過一個廣電系統的原型,故使用

NABCD 模型

N —— Need,需求

我們的平臺具有以下功能:

  1. 用戶可給定論文列表
    • 通過論文列表,爬取論文的題目、摘要、原文鏈接
    • 可對論文列表進行增刪改操作(今年、近兩年、近三年)
  2. 對爬取的信息進行結構化處理,分析 top 10 個熱門領域或熱門研究方向
    • 可對論文屬性(oral、spotlight、poster)進行篩選及分析
    • 形成如熱詞圖譜之類直觀的查看方式
  3. 可進行論文檢索,當用戶輸入論文編號、題目、作者等基本信息,分析返回相關的 paper、source code、homepage 等信息
  4. 可對多年間、不同頂會的熱詞呈現熱度走勢對比(這裏將範疇限定在計算機視覺的三大頂會 CVPR、ICCV、ECCV 內)
  5. 可進行數據統計,例如每個國家錄用文章的分析、每個學校錄用文章的分析、哪個學校哪方面的研究方向比較強等
  6. == 附加需求一:用戶可以根據科研方向選擇興趣小組加入,尋找誌同道合的研友,交流經驗、交流學術、交流感情、一起發paper。 ==
  7. == 附加需求二:用戶可以對論文摘要做讀書筆記,進行修改標註、便於再次閱讀、整合歸納。 ==

A —— Approach,方法

  • 我們的平臺基於 web實現。有如下優勢:
    • web 端方便用戶訪問,無需額外下載客戶端。
    • web 端叠代速度快,產品升級代價小
    • web 端無論在 PC 還是在移動設備都可以訪問,打破了平臺的限制
  • 針對需求1 —— 本平臺通過論文列表,爬取論文的題目、摘要、原文鏈接
    • 若用戶給出鏈接,則通過爬蟲實現對用戶給出的論文列表進行爬取,並將得到的結果返回前端,方便用戶進一步篩選。
    • 若用戶給出的是文件,則讀取文件得到論文題目,進入三大庫和兩大索引庫等返回結果。
    • 鏈接僅限制為計算機視覺的三大頂會 CVPR、ICCV、ECCV 的官網。
    • 文件僅限制為 EXCEL 文件,表格模板如下:
      技術分享圖片
    • 采用鏈接文件的優勢如下:
      • 簡易性:用戶僅需提供鏈接即可獲得論文列表,為用戶減少了大量繁復的工作,體現了智能性。
      • 針對特定需求:有些用戶有很明確的閱讀目標,他並不需要會議的所有論文,只需要某些論文的某些信息。本平臺可以通過導入一個excel文件,進行特定場景下的檢索。
  • 針對需求2 —— 本平臺可對論文列表進行增刪改操作(今年、近兩年、近三年)
    • 用戶對平臺給出的論文列表進行篩選,例如刪除某些年份論文,刪除不感興趣的論文。
  • 針對需求3 —— 本平臺可對論文屬性(oral、spotlight、poster)進行篩選及分析
    • 用戶可以在一系列論文中根據論文屬性進行選擇性的查看
  • 針對需求4 —— 形成如熱詞圖譜之類直觀的查看方式
    • 用戶可以選定一系列論文進行分析與統計,得到的結果以圖表方式返回。例如以關鍵詞形成詞雲:
      技術分享圖片
  • 針對需求5 —— 本平臺可進行論文檢索
    • 用戶可以輸入論文編號、題目、作者等基本信息,然後通過三大庫和兩大索引庫等論文庫進行搜索,得到的結果返回前端。
  • 針對需求6 —— 本平臺可對多年間、不同頂會的熱詞呈現熱度走勢對比
    • 事先爬取好信息並分析統計好結果,當用戶需要時直接調出。
  • 針對需求7 —— 本平臺可進行數據統計
    • 對論文的作者在搜索引擎內進行搜索,得到作者的國家、工作單位。至於哪個學校哪方面的研究方向比較強這個需求則是統計出各學校在各方向發表的論文數,以此來評判強與弱。

B —— Benefits,好處

  • 使用方便:本平臺基於 web 實現,用戶打開瀏覽器輸入網址即可使用
  • 節約時間:批量檢索論文,大大減少檢索論文時的時間開銷。
  • 數據分析:根據呈現出來的熱度走勢對比緊跟科研潮流
  • 尋找研友:可以尋找誌同道合的人,創建興趣小組,與有共同科研方向的人交流。

C —— Compettors,競爭

優勢

  • 可以尋找誌同道合的科研朋友,創建興趣小組,方便交流,加入社交元素,加速科研進展。
  • 可以進行數據分析,針對不同的熱度,尋找適合自己、自己更感興趣的方向,走在最前沿。
  • 基於 web 實現,易於更新叠代。
  • 保證通用性和特定場景下的論文列表需求。

劣勢

  • 支持兩種方式導入論文列表,鏈接的方式具備通用性,但不能滿足所有人的需求;Excel 導入的方式,可以讓用戶針對需求自定制論文列表,但是缺少普適性。
  • 鏈接方式僅支持三個最前沿最熱門的會議,未能雨露均沾,只能保證本方向的前沿性權威性。

D —— Delivery, 推廣

  • 從本實驗室的學長學姐們開始推廣,進行小範圍的測試,修復 bug,並完善產品。
  • 從本學院的實驗室進行推廣,擴大範圍,制作傳單,通過掃碼即可進入平臺。
  • 在學院內市場飽和之後,向整個學校推廣。經過同意後,在各學院張貼海報,掃碼使用平臺。

閱讀《構建之法》及成果

閱讀的感想很多,挑選感觸頗深的一點談談

我們要充分了解用戶的痛苦,他們對已有軟件、服務不滿意的地方。但是用戶往往也不了解顛覆型的創新。例如,不但用戶不太能描述自己的需求,有時候開發者也陷人固定的“產品導向”的思維, 開發網站的,就認為用戶一定需要一個網站; 開發移動應用的, 就認為用戶一定需要一個 App。事實上,用戶並不需要“產品”,用戶需要解決痛點的方案”。

  • 不但用戶不太能描述自己的需求,有時候開發者也陷人固定的“產品導向”的思維。 通過在原型設計過程和需求了解過程中,發現其實用戶的 需求是最最關鍵的一環。設計的過程,其實也是和用戶打交道的過程,設計的過程,也是需求不斷明確的過程,
  • 用戶並不需要“產品”,用戶需要解決痛點的方案”。 用戶並不關心你的產品提供的什麽樣的算法、基於什麽平臺實現,而是是否解決了他的痛點、滿足了他的需求。所以在設計時,一定要以用戶為核心,學會換位思考,考慮是否滿足了用戶的需求。

結對過程

技術分享圖片
淩晨兩點的軟工工作室
技術分享圖片
技術分享圖片

遇到的困難及解決方法

  • 對的需求理解的不夠到位
    • 請教助教後得到解惑
    • 相互討論後得到答案
    • 詢問同學得到結果
  • 第一次使用原型工具,不熟練
    • 墨刀對新手較友好,但是某些功能操作復雜,通過查看教程得到答案。
    • 通過自己摸索熟練操作
  • 對平臺的設計產生疑問
    • 查找 IEEE 的官網,作為搜索引擎的參照
    • 查找 web of sci,作為數據部分分析的參照

原型實現

  • 通過上傳文件提供鏈接兩種方式,得到論文列表
    技術分享圖片

  • 顯示論文的相關信息,如摘要,並提供文檔編輯標註功能,便於進行做閱讀筆記
    技術分享圖片
  • 顯示論文列表,可以對查看論文的摘要、全文等信息
    技術分享圖片
  • 對論文進行增刪改功能,便於管理,並進行用戶需求的定制化
    技術分享圖片
  • 提供搜索功能,可以進行高級檢索,對近三年的論文進行檢索
    技術分享圖片
  • 全文顯示,用戶點擊查看後,顯示論文全文。
    技術分享圖片
  • 提供對三大頂會的數據統計,以餅狀圖的形式呈現。
    技術分享圖片
  • 針對世界、不同國家、學校的科研水平進行統計分析
    技術分享圖片
  • 對論文的熱詞進行統計、分析
    技術分享圖片
  • 創建、加入興趣小組,尋找科研方向上誌同道合的朋友
    技術分享圖片

PSP表格

PSP2.1 Personal Software Process Stages 預估耗時(分鐘) 實際耗時(分鐘)
Planning 計劃 120 100
· Estimate · 估計這個任務需要多少時間 120 110
Development 開發 1970 2130
· Analysis · 需求分析 (包括學習新技術) 20 120
· Design Spec · 生成設計文檔 120 90
· Design Review · 設計復審 30 20
· Coding Standard · 代碼規範 (為目前的開發制定合適的規範) 0 0
· Design · 具體設計 1740 1830
· Coding · 具體編碼 0 0
· Code Review · 代碼復審 30 10
· Test · 測試(自我測試,修改代碼,提交修改) 30 60
Reporting 報告 75 70
· Test Repor · 測試報告 0 0
· Size Measurement · 計算工作量 15 20
· Postmortem & Process Improvement Plan · 事後總結, 並提出過程改進計劃 60 50
合計 2165 2310

學習進度條

第N周 新增代碼(行) 累計代碼(行) 本周學習耗時(小時) 累計學習耗時(小時) 重要成長
1 0 0 5 5 閱讀《構建之法》,重點了解了 NABCD 模型
2 0 0 10 15 找到了適合團隊的原型工具,以及如何並行操作

總結

基於web,設計了一個多功能論文管理平臺的原型。用戶可以通過文件導入鏈接導入兩種方式爬取導出論文列表,滿足了通用性和特定的應用場景的需求。可以對近三年論文列表進行增刪改操作,完成論文列表的定制化。在論文相關數據導入完成後,平臺將生成數據對比分析,分析 top 10 個熱門領域或熱門研究方向,便於用戶尋找熱門和感興趣的研究方向。並對論文屬性進行篩選及分析,形成如熱詞餅狀圖、熱詞柱狀圖之類直觀的查看方式。用戶還可以對論文列表進行檢索,當用戶輸入論文編號、題目、作者等基本信息,分析返回相關的 full paper、abstrct 等信息。提供了兩個附加功能。用戶可以編輯論文摘要,並做好做讀書筆記。也可以尋找誌同道合的科研朋友,創建科研興趣小組,交流經驗、交流學術。

體會

  • 掌握了墨刀的使用方法。相比較 Axure Rp 墨刀對新手還是比較友好的,但是專業性確實會略輸一籌,不過對於這次軟工作業來說足夠了。
  • 掌握了 NABCD 模型。一開始我還不了解為什麽要看《構建之法》,現在我理解了,沒看之前我們完全找不到思路,後來閱讀之後就有了比較明確的流程去完成需求。
  • 很早就抱好了周學長的大腿。結果由於兩個都有很多事情壓得喘不過氣,於是拖到了 deadline 之前才完成,時間管理做的還是不夠好。
  • 最後感謝周學長的一起努力~

軟工之 NABCD 模型分析及 Web of Paper 原型設計結對作業