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

課程: 軟件工程1916|W(福州大學)
做業要求: 結對第一次—原型設計(文獻摘要熱詞統計)
結對成員:131601207 陳序展221600440 鄭曉彪
本次做業目標: 閱讀《構建之法》,針對小櫻瞭解頂會論文研究熱點的需求以結對的形式進行軟件的需求分析以及原型設計,初步體驗兩人合做的需求分析和原型設計過程
原型設計:頂會熱詞統計系統
附件:結對第一次—原型設計(文獻摘要熱詞統計).PDFweb

基於NABCD模型的需求分析

1. N(Need,需求)

礙於時間緊促,原型製做工具使用笨拙,在基本分析設計了基本需求的界面和功能的基礎上,一些附加需求的分析和設計都有待完善

基本需求:數據庫

小櫻是一名大三的學生,一直癡迷於吃雞類遊戲,某日聽聞同宿舍的小狼剛和導師去參加了CVPR會議,心裏羨慕不已,便下定決心痛改前非、努力鑽研,但願能在畢業前完成一篇站在時代前沿的優秀論文。但使人苦惱的是,他不知道近幾年頂會的熱門領域和研究方向,根據論文list去一篇一篇查找總結效率又着實過低,因而求助於「軟工實踐互助愛心組織」,但願咱們能幫助他設計一個平臺解決現階段的需求。但願此平臺至少具有如下功能:編程

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

附加需求:微信

  • 增長了用戶登陸、註冊的功能,網站須要有私人操做
  • 可在線導出參考文獻格式
  • 用戶可收藏及分享感興趣的論文
  • 用戶能夠對相關做者進行關注,以便了解到該做者的最新成果

2. A(Approach,作法)

作了需求分析後,咱們繪製了思惟導圖,將需求對應的功能放置到了不一樣的頁面中去app

  • 登陸頁/註冊頁
    • 提供用戶登陸註冊功能
    • 三大頂會介紹輪播
  • 檢索主頁
    • 簡單檢索:根據用戶輸入檢索頂會論文
    • 高級檢索:支持用戶的多輸入檢索
    • 批量檢索:支持用戶批量論文統計分析
    • 三大頂會logo、簡介
  • 檢索結果頁
    • 論文信息列表:呈現檢索的論文列表結果,有摘要、排序兩種查看方式,可排序
    • 頂會熱詞分析:點擊進入頂會熱詞分析頁,可根據選擇會議範圍、年份範圍呈現對應的熱度走勢折線圖
    • 左側數據統計欄:分爲國家、學校,對錄用的文章數量進行統計,其中學校下又分具體研究方向,對學校研究方向進行統計
  • 論文詳情頁
    • 顯示較詳細的論文信息
    • 提供pdf下載
  • 批量搜索頁
    • 論文列表的輸入、導入、導出
    • 爬取論文信息:對輸入或導入的論文列表爬取其中的標題,關鍵詞,摘要,原文地址
    • 論文信息處理:
    • 對爬取結果可篩選oral、spotlight、poster三種屬性
    • 可篩選「近一年」、「近兩年」、「近三年」三種年限的論文
    • 點擊「TOP10」按鈕進入論文列表內容熱詞的分析頁面,分別以圖譜、柱狀圖、折線圖、扇形圖的形式呈現

3. B(Benefit,好處)

  • 基於web端實現,具備跨平臺的特性,一次開發便可知足多端,開發成本低,能夠即時更新,保證全部用戶訪問的版本一致,且用戶使用成本低
  • 對於論文數據的分析提供了諸如關鍵詞圖譜、柱狀圖、折線圖等直觀的表現形式,便於用戶查看
  • 能夠批量導入論文,方便用戶一次進行多篇論文的檢索,同時增長了對於論文列表的動態增刪改處理以及根據年份的篩選功能
  • 由於咱們目前的搜索只針對計算機視覺領域的三大頂會CVPR、ICCV、ECCV,因此搜索結果更具備精確性

4. C(Competitors,競爭)

學術搜索是一個十分具備發展前景的領域,在學術搜索方面,目前市面上有中國知網,百度學術,萬方智搜等一些學術搜索平臺,相比於這些學術搜索平臺,咱們的平臺所具備的優點和劣勢以下:工具

  • 優點
    一、目前的學術搜索平臺並不支持批量檢索的功能,而咱們的平臺支持批量檢索的功能,便於用戶一次進行多篇論文的檢索,提升了用戶的檢索效率
    二、目前只針對於計算機視覺領域的三大頂會CVPR、ICCV、ECCV,因此搜索結果更具備專業性、精確匹配性
    三、界面更加美觀,易於用戶使用操做
    四、對於檢索結果,提供了諸如關鍵詞圖譜、柱狀分析圖、折線分析圖、餅狀分析圖等直觀的表現形式,利於用戶使用
    五、頂會熱詞提供了頂會近年來TOP10熱詞,便於用戶瞭解當前的學術趨勢post

  • 劣勢
    一、相比於其餘學術搜索平臺,咱們的數據庫較小,檢索內容有限
    二、UI界面人機交互性不足,缺少美感
    三、功能分配尚需改進學習

5. D(Delivery,推廣)

  • 線上推廣
    • 經過付費的搜索引擎推廣網站
    • 聯繫一些網站管理人員添加網站友情連接
    • 經過貼吧,微信朋友圈,微博,QQ等獲取關注...
  • 線下推廣
    • 在校園周邊進行推廣

原型設計

原型設計工具:墨刀測試

登陸註冊頁:
優化


主頁:

檢索結果頁:

點擊「頂會熱詞」查看頂會熱詞統計分析

批量搜索頁:

點擊「TOP10」進入批量論文分析

結對過程

結對照片

遇到的困難及解決方法

困難描述
一、在一開始對於需求有些地方不理解,如對論文列表進行增刪改操做後面有個備註今年、近兩年、近三年是什麼意思
二、咱們對需求在原型設計中的權重安排,對功能在界面上的安排一直難以取捨
三、因爲咱們都是第一次接觸原型設計這個概念,也是第一次使用原型設計工具——墨刀,所以一開始對於墨刀的使用有些不熟悉
解決嘗試
一、經過討論,認爲今年、近兩年、近三年這三個條件能夠做爲篩選項,對論文爬取結果列表進行篩選
二、商量重要需求和通常需求,對重要需求,其功能在原型設計時可能要另外加頁面,而一些通常需求只須要有所表示便可。如本次原型設計中的熱詞分析部分和論文批量處理部分,咱們都安排了另外的頁面;而對國家、學校以及學校研究方向的統計分析,咱們縮放到檢索結果頁中的一個側邊欄,讓用戶能在搜索時看到數據就行了
三、經過查看教程,實際使用,不斷提升使用墨刀進行原型設計的能力
是否解決
一、已解決
二、已解決
三、已解決

有何收穫

經過閱讀《構建之法》一書和此次實際結對完成做業,對於結對編程的概念有所理解,並經過實踐加深了理解,也對原型設計的理念有所瞭解。同時掌握原型設計工具——墨刀的基本使用方法。

  • 131601207 陳序展

    我是在軟件工程的第一節課上第一次聽到結對編程這個「新名詞」的,第一時間我就經過百度搜索,瞭解告終對編程的基本概念,很快地就找定了本身的隊友,後來經過閱讀《構建之法》4.5節的內容,對於結對編程的定義有了進一步的理解。在此次的原型設計的過程當中,由於整體設計的時間比較長,因此我與隊友之間「領航員」與「駕駛員」的角色時常互換,在實際的設計過程當中,我深入的體會了這種合做方式的好處,在我進行具體設計的時候,隊友總能夠提出一些我想不到的好點子優化個人設計,而在隊友進行設計的時候,我也能夠提出一些新的想法,不斷地優化咱們的設計。固然咱們在實際的設計過程當中也發現了一些問題,好比一開始咱們可能對一些具體功能只有一些基本的設想,並無制定好詳細的設計方案,致使在設計的過程當中,咱們的設計一改再改,浪費了許多時間,這是咱們須要總結並改進的方面。整體來講,咱們的結對過程仍是比較良好的,咱們都很積極主動的參與任務,並無產生大的分歧,互相均可以積極的聽取對方的建議。固然,除了收穫了對於結對編程的實際體驗,加深了對於結對編程的理解,我也在實際設計的過程當中,掌握了原型設計工具——墨刀的基本使用方法。

  • 221600440 鄭曉彪

    經過本次對「小櫻」需求的分析以及文獻摘要熱詞統計原型設計的實踐,我體會了兩人合做,雖然時間只有短短五天,可是天天想着小櫻的需求,想着原型怎麼分配功能,怎麼作的好看、合理,兩我的提出了不少想法也參考了別人的作法。這麼多想法的碰撞很難不和隊友產生矛盾,很幸運,和結對夥伴的結對過程還算順利。就如書中提到的結對過程是一個互相督促的過程,駕駛員和領航員的角色是要時常互換的。由於咱們都很難一眼看透用戶需求,很難一下想到大部分功能,並且長時間緊張工做會使咱們的觀察力和判斷力降低,因此整個過程,我和隊友都是相互分享,有不一樣的想法就多思考,多參考,相互幫助,最後商量出統一的方法來,我想這在以後團隊更多人的合做裏是更爲重要的。不過雖然過程比較順利,可是我也發現了在這過程當中本身的問題:
    一、在看到需求的時候對功能設計的思惟不夠發散,多是眼界和設計實踐的侷限所致
    二、參考越多本身越不知道作什麼,這也想加,那也想改的,很頭疼
    因此,我也很感謝隊友,在結對過程當中能提出個人問題,提出他的想法。

效能分析和PSP

效能分析:

根據《構建之法》2.2節的內容,效能分析是對於程序代碼的分析,因爲咱們的平臺目前還停留於原型設計階段,並無進行效能分析

PSP:

PSP是卡耐基梅隆大學(CMU)的專家們針對軟件工程師所提出的一套模型:Personal Software Process (PSP, 我的開發流程,或稱個體軟件過程)

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