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


做業要求前端


這個做業屬於哪一個課程 軟件工程1916-W(福州大學)
這個做業要求在哪裏 結對第一次—原型設計(文獻摘要熱詞統計)
結對學號 221600414221600417
這個做業的目標 學習原型設計工具,理解NABCD模型,提升需求分析
其餘參考文獻 [1]鄒欣.構建之法[M]

NABCD模型web


  • N(Need,需求)
    • 整體:高效率地獲取近幾年頂會的熱門領域和研究方向算法

    • 進一步細分以後,用戶需求將分爲這幾個部分:數據庫

    • 用戶可給定論文列表
      • 經過論文列表,爬取論文的題目、摘要、關鍵詞、原文連接;
      • 可對論文列表進行增刪改操做(今年、近兩年、近三年);
    • 對爬取的信息進行結構化處理,分析top10個熱門領域或熱門研究方向;
      • 可對論文屬性(oral、spotlight、poster)進行篩選及分析;
      • 造成如關鍵詞圖譜之類直觀的查看方式;
    • 可進行論文檢索,當用戶輸入論文編號、題目、關鍵詞等基本信息,分析返回相關的paper、source code、homepage等信息;
    • 可對多年間、不一樣頂會的熱詞呈現熱度走勢對比(這裏將範疇限定在計算機視覺的三大頂會CVPR、ICCV、ECCV內)。
    • 可進行數據統計,例如每一個國家錄用文章的分析、每一個學校錄用文章的分析、哪一個學校哪方面的研究方向比較強等。編程

    將用戶的需求進一步整理,明確所須要的功能以及邏輯流程:微信

    功能圖:
    併發

    邏輯流程圖:
    app

  • A(Approach,方法)
    • 熱度檢測
      • 用戶輸入或批量導入待爬取的論文列表或者會議名稱。
      • 系統爬取相應的論文列表並在前端顯示爬取成功的論文列表(類型、題目,摘要,關鍵字,原文連接)。
      • 用戶可對爬取結果列表進行增刪查改。
      • 篩選完畢以後提交至後臺進行熱度檢測。
      • 前端生成關鍵詞圖譜(雲圖),熱度一目瞭然。
      • 用戶能夠只篩選某一類別(oral、spotlight、poster)的熱點論文研究方向查看關鍵詞圖譜。
    • 論文搜索
      • 用戶輸入論文編號、題目、關鍵詞等搜索條件進行搜索。
      • 檢索結果以卡片的形式順序展現在頁面上,用戶能夠依次瀏覽各個論文的內容。
      • 各個論文展現出該論文的題目和源碼部分,用戶若是對該論文感興趣,可點擊閱讀原文跳轉到原文位置進行全文閱讀。
    • 熱詞分析
      • 系統給出所列論文的熱詞。
      • 用戶可選擇一至多個熱詞進行分析。
      • 頁面根據用戶的分析條件,對三大頂會(CVPR,ICVV, ECVV)的熱詞進行分析,以柱狀圖的形式展現出三大頂會的不一樣熱詞之間的熱度關係。
    • 數據統計
      • 用戶經過選擇學校和國家,展現出不一樣學校和國家的熱點研究領域的餅狀圖,研究熱度一目瞭然。
      • 經過對每一個國家錄用文章的分析、每一個學校錄用文章的分析,系統展現出不一樣國家和不一樣學校的某一個領域的研究強項評分。
      • 以表格的形式展現出TOP5的某個研究領域的排名。
      • 用戶能夠進一步選擇感興趣的研究領域進行排行,查看該領域研究能力比較強的高校排名。。
  • B(Benefit,好處)
    • 客戶端採用web的方式
      • 用戶隨時隨地能夠訪問站點,免去安裝應用的麻煩。
      • 站點升級優化方便快捷,用戶體驗不打折扣。
    • 支持用戶登陸註冊
      • 一個帳號隨處可用,登陸便可查看瀏覽記錄,一鍵收藏,隨時查看。
    • 數據顯示直觀,圖表分析一目瞭然
      • 採用大號字體和表格,排版簡潔清晰。
      • 熱點論文數據結合柱狀圖、折線圖、雷達圖等各個樣式的圖標,數據一覽無餘。
    • 搜索篩選高度自定義
      • 用戶可對搜索論文加以年份、屬性、所屬國家、高校等條件加以限制,使檢索結果更加準確。
      • 可在檢索結果之上進行二次檢索,縮小目標論文的範圍,獲取所需信息更加方便快捷。
  • C(Competitors,競爭)
    • 智能推送熱點論文,檢索一步到位
      • 據咱們所知,目前比較權威的幾個論文檢索網站對用戶數據方面的支持都不怎麼好,基本上就是用完就走,每次都要從新開始檢索數據庫,對用戶很不友好。而咱們的站點能夠保存用戶的檢索記錄,以及收藏功能,將用戶的使用記錄加以處理,後期可使用推薦算法,給不一樣的用戶推送不一樣研究方面的高引、熱點論文,使檢索過程更加方便快捷。
    • 界面設計簡潔大氣,操做簡單,上手容易
      • 界面採用卡片式左右佈局,左側爲菜單欄,右側爲功能區,用戶可根據我的需求隨意切換,檢索框和篩選框採用大中型輸入框和複選框,採用大號字體,檢索結果列表整齊美觀,使用戶更加容易上手操做,比起其餘的站點,具備更強的競爭優點,更加順暢的用戶體驗。
    • 零門檻起步,零費用體驗
      • 據咱們調研,國內多個論文檢索網站多多少少均存在部分功能收費的狀況,而咱們的網站所有功能均無償使用,無任何費用,這對於用戶來講是一個很大的吸引點,十分具備競爭性。
  • D(Delivery,推廣)
    • 線下推廣
      • 能夠藉助咱們學生的優點,在大學城各大校園裏,採用發傳單、張貼海報的形式,讓同窗們近距離了解咱們的網站,互相宣傳通知。因爲大學生是查找論文資料的第一羣體,所以在大學生羣體之間推廣,能夠迅速讓他們成爲咱們的第一批用戶。
    • 線上推廣
      • 在各個社交媒體上進行廣告投放,吸引相關的羣體註冊登陸。讓同窗們在QQ、微信、微博中積極轉發,讓更多的人瞭解咱們的網站,使用咱們的產品。

原型設計工具



登陸界面佈局

  • 首頁簡潔清晰,沒有任何干擾物
  • 背景爲一團聚合的煙霧,意爲 在海量零碎的論文信息中,挖掘其中的價值
  • 項目名爲 熱度嗅探,與背景相呼應
    1_登陸

首頁(熱度檢測)

  • 左側爲導航欄,右方爲功能區
  • 畫風簡約
  • 內容顯示具備立體感
    2_首頁
    2_1_熱度檢測2

論文搜索

  • 檢索結果將論文以卡片的形式進行展現
    3_論文搜索

熱詞分析

  • 柱狀圖顏色分明,樣式美觀
    4_熱詞分析

數據統計

  • 統計結果一目瞭然
    5_數據統計

結對過程




總結


  • 結對心得(馮凱)
    經過本次結對過程,我學習到了如何與隊友進行分工合做去完成一個任務,之前作做業,基本上都是咱們單獨去完成的,本身作起來比較駕輕就熟,不用考慮其餘的因素,然而在團隊做業中,咱們須要密切配合,商量好分工,每一個人承擔一部分工做量,還要搭配得當,不斷交流。
  • 項目總結(馮凱)
    這個項目對於我來講是一個全新的任務,在讀完一遍做業要求後,感受迷迷糊糊,不是很懂題目的意思,不知道從哪裏開始寫起,光是討論項目內容就花費了一個多小時,在理解了項目需求以後,才知道怎麼去作。因爲以前不多接觸到原型設計工具,因此花費了很長時間去學習使用墨刀設計原型,也算是又學會了一項技能吧,之後再遇到須要設計的東西,就能很快作出來了。
  • 遇到的困難以及解決方法(馮凱)
    初期需求分析過程當中,感受需求很繁雜,所以使用圖標的方式將需求逐個列了出來,待目標明晰以後再開始開發。在原型設計階段,剛開始設計的界面比較簡陋,不夠美觀,後面經過參考一些網站的設計界面,再結合本身項目的需求,逐步設計出佈局美觀的界面。
  • 結對心得(黃樂興)
    在此次結對的開始,咱們討論出了一個理想的任務分配方案。但好景不長,等到咱們開始工做的時候,就發現每一個人的任務之間存在着依賴關係,並不能併發進行。此次的任務不一樣以往,整個任務較爲緊湊,並不能輕易地進行劃分切割。最後,咱們兩個一塊兒分析了需求,併合並了兩我的在理解上的衝突, 規劃了這個項目所需的全部功能點以及每一個功能的具體實現過程。
  • 項目總結(黃樂興)
    經過本次的項目,我對於結對編程有了進一步的理解。結對編程的目的是提升開發效率,但這個前提是分析出整個項目的子任務以及任務之間的關係。對於本次的需求分析以及原型開發任務,須要兩我的對需求展開各自的理解,並整合出一份較好的實現過程。當咱們有了一個共同的想法以後,就能夠開展一些可並行的任務。例如,在功能的實現已經有了共同的想法以後,一我的能夠進行相關的原型開發,另外一我的能夠進行功能的文檔編寫。
  • 遇到的困難以及解決方法(黃樂興)
    本次遇到的困難主要有三點。 第一點是:需求分析,解決方法是:找到整個需求的初衷,以這個初衷爲基礎,進一步地分析出每一個需求點的本質,試圖站在用戶的角度思考每一個需求。 第二點是:原型設計開發,解決方法是:閱讀官方教程,並在相關論壇裏面找到有關的技術經驗。一個好的技術經驗可以加快整個開發的過程。 第三點是:導出圖片,大部分人導出的圖片較爲模糊,但做爲一份客戶推銷的文案,咱們應該儘量地讓客戶看到一個好的項目。解決方法是:百度搜索相關問題,解決步驟即爲 1.放大200% 2.下載導出png

效能分析及PSP


  • 效能分析
    本次做業咱們在結對過程當中完成了需求分析以及原型設計部分,不管是分析階段仍是設計階段,能夠說是花了很大的心思去準備的,所以完成效果應該仍是很不錯的。至於效率方面,若是打個分的話,應該只有七十幾,緣由就是第一次在這種創新的課程模式下去完成做業,多多少少有些不太習慣,在合做中碰到很多的問題,花費很大的時間去查找緣由,解決問題,加上初次使用原型設計工具,所以在設計過程當中進展十分緩慢。後面若是須要具體去實現的話,應該是比較快的, 由於在代碼方面,咱們比較熟悉,寫起來比較快,效率會高一些。並且咱們的網站在設計初期實現了客戶的全部需求,還有本身擴展的功能,能夠說是十分具備吸引力。
  • PSP表格

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

博客內容下載(PDF版本)


點擊下載

相關文章
相關標籤/搜索