結對第一次—原型設計(文獻摘要熱詞統計)

做業課程:軟件工程實踐
做業要求:結對第一次—原型設計(文獻摘要熱詞統計)
結對學號:221600111 | 221600138
做業目標: 理解用戶需求及構建原型,鍛鍊合做能力web

NABCD模型

1. N(Need 需求)

根據小櫻的訴求,咱們總結出如下幾點客戶需求:數據庫

  • 用戶可以經過輸入已有的論文列表讓系統自動提取論文的題目、摘要、關鍵詞以及原文連接;
  • 在進行檢索時用戶可以指定選取今年、近兩年、近三年等時間段的論文;
  • 在檢索以後用戶但願獲得的信息不僅是論文列表及連接,還須要對全部的論文信息進行處理,顯示出10個熱門的領域或者研究方向同時將論文的全部相關關鍵詞以圖表形式顯示,讓用戶可以直觀查看;
  • 在已經顯示的搜索結果的基礎上經過選擇論文屬性(oral、spotlight、poster等)再進行二次檢索;
  • 用戶可以在檢索框中輸入論文編號、題目、關鍵詞等基本信息,從而獲得所需的paper、source code、homepage等信息;
  • 檢索後的界面須要對比計算機視覺的三大頂會(CVPR、ICCV、ECCV)多年間的熱詞熱度的走勢;
  • 用戶可以獲得有關每一個國家錄用文章的分析、每一個學校錄用文章的分析、哪一個學校哪方面的研究方向比較強等方面的數據統計圖。

2. A(Approach 作法)

① 提供一個web端平臺讓用戶可以進行直接的檢索;
② 如今不少用戶都是用手機瀏覽器,故還需設計一版適合手機分辨率的界面;
③ 用戶在登陸後能夠上傳須要處理的論文列表,通過篩選處理後,用戶可以得到處理後的列表及分析結果。用戶能繼續對處理後的列表進行操做,相似二次檢索。瀏覽器

3. B(Benefit 好處)

① 本系統幫助用戶整理和分析文獻,節約用戶獲取重要信息的寶貴時間;
② 用戶在須要使用論文分析服務時,必然會頻繁用到本系統,故:
web端更加輕便,很適合隨時隨地進行論文處理;
不須要動用用戶的設備進行計算,用戶因花費時間等待處理,體驗更加友好;
③ 即學即用,操做簡便,無需太多複雜過程。服務器

4. C(Competitors 競爭)

劣勢:
1)委託人需求的功能難度都較高,須要用到業界前沿知識才能實現
2)論文資源的來源較難獲取;
3)如今必然已有機構實現相關業務,本產品競爭壓力大;
4)計算量大,服務器負載太高容易致使系統崩潰(看看福大易班)
優點:
1)相較於普通瀏覽器來講,咱們的產品更加的符合用戶的使用理念,可以更加有效、快速、方便的解決用戶對於該方面的需求;
2)相對於手機app而言,使用web端可以減去較爲繁瑣的下載安裝軟件並進行升級的步驟;
3)一站式論文處理分析,優化用戶體驗;
4)系統功能實用,還能派生出其餘文檔分析業務。app

5. D(Delivery 推廣)

一個方案是與現有的一些資料文庫合做(如讀秀、超星、知網等),能夠從他們中獲取相關的論文信息並向其用戶進行宣傳,同時爲其提供相應服務;也能夠與各大高校合做,與其圖書館數據庫相聯繫,爲全部有需求的高校生服務,利用各大高校來進行產品的推廣。工具

結對過程


結對討論圖

草圖post

原型設計

使用工具:Microsoft Office PowerPoint 2016
頁面統計:主頁,搜索結果頁,文件處理頁共3頁(實際應該須要更多頁面,這裏暫時沒有餘力設計)
功能設計:「文件處理頁」完成論文列表的處理及部分分析功能,「搜索結果頁」完成數據統計及搜索功能學習

主頁部分

主頁能夠以文獻檢索/上傳列表兩種方式工做
測試

在上傳列表功能中,用戶能夠上傳多個論文列表(圖中是excel文件),能夠查看文件上傳進度(進度100%後顯示綠勾符號)及取消誤傳文件優化

在主頁用戶若是沒有登陸,點擊任何功能都會彈出登陸框,用戶登陸後才能提供服務(這麼好的系統不能白用)

處理頁部分


分部說明
① 論文列表,用戶上傳的論文列表通過分析處理後統一顯示在這裏,點擊關鍵字後,論文列表自動篩選出相關關鍵字的文獻
②論文全文查看窗口,用戶點擊某篇論文,能夠查看全文(若是第三方數據庫支持的話?)右下角三個按鈕的功能爲:在新窗口轉到該論文、標記/收藏、刪除(從本列表中刪除這篇論文)
③關鍵詞統計,點擊關鍵字後,論文列表自動篩選出相關關鍵字的文獻
④擔憂誤刪誤點?這裏提供了撤銷/前進功能,第三個是下載(處理後的列表),第四個是添加過濾器(時間之類),最後一個是提交按鈕
⑤當前視圖的過濾器(用戶能夠刪除某個過濾器)

搜索頁部分

模仿別的文獻平臺的設計,不須要太多說明,經過上方的條件,及餅圖的組合,便可查看不一樣國家、不一樣學校、學校主攻方面等的數據統計圖

PSP表格

PSP2.1 Personal Software Process Stages 預估耗時(分鐘) 實際耗時(分鐘)
Planning 計劃 20 35
• Estimate • 估計這個任務須要多少時間 40 45
Development 開發 200 360
• Analysis • 需求分析(包括學習新技術) 30 60
• Design Spec • 生成設計文檔 20 30
• Coding Review • 設計複審 5 10
• Coding Standard 代碼規範 (爲目前的開發制定合適的規範) 0 0
• Design • 具體設計 0 0
• Coding • 具體編碼 0 0
• Code Review • 代碼複審 0 0
• Test • 測試(自我測試,修改代碼,提交修改) 0 0
Reporting 報告 30 45
• Test Report • 測試報告 0 0
• Size Measurement • 計算工做量 10 10
• Postmortem & Process Improvement Plan • 過後總結, 並提出過程改進計劃 20 20
合計 375 595

總結

草圖一時爽,原型火葬場,設計原型常常要站在用戶的角度想客戶提出的需求是否是獲得瞭解決,是否是缺了哪些功能,哪些板塊。此次的做業鍛鍊了咱們團隊合做的能力,合做時到處會有磕碰,常常會一我的的想法提出來很快被另外一我的否認,兩我的沒有想到一塊去,但好處就是經過討論系統的功能也愈來愈完善,交互體驗不斷優化。

本文PDF文件

點擊下載

相關文章
相關標籤/搜索