軟件工程第二次做業(原型設計)

課程名稱:軟件工程實踐
做業要求:結對第一次—原型設計(文獻摘要熱詞統計)
結對學號:221600428 | 221600438
做業目標:瞭解NABCD模型,學習創建軟件原型
原型工具:墨刀
PDF連接:下載PDF程序員

NABCD模型數據庫

  • N(Need)
    • 用戶可給定論文列表
    • 經過論文列表,爬取論文的題目、摘要、關鍵詞、原文連接;
    • 可對論文列表進行增刪改操做(今年、近兩年、近三年);
    • 對爬取的信息進行結構化處理,分析top10個熱門領域或熱門研究方向;
    • 可對論文屬性(oral、spotlight、poster)進行篩選及分析;
    • 造成如關鍵詞圖譜之類直觀的查看方式;
    • 可進行論文檢索,當用戶輸入論文編號、題目、關鍵詞等基本信息,分析返回相關的paper、source code、homepage等信息;
    • 可對多年間、不一樣頂會的熱詞呈現熱度走勢對比(這裏將範疇限定在計算機視覺的三大頂會CVPR、ICCV、ECCV內)。
    • 可進行數據統計,例如每一個國家錄用文章的分析、每一個學校錄用文章的分析、哪一個學校哪方面的研究方向比較強等。
  • A(Approach)
    根據需求,咱們打算一個Web的網頁原型設計。首先切割功能需求,使頁面更加的合理,提升頁面的開發速度,減輕編程量。
    咱們將全部的功能以及展現劃分爲六個頁面,分爲主頁面、導出論文信息、關鍵詞圖譜分析、不一樣頂會熱詞呈現的熱詞走向趨勢、學校錄用論文分析、國家錄用論文分析六大主要頁面。另外論文信息檢索的界面是直接以網絡搜索引擎的檢索結果爲準。
    一、主頁面:
    (1)將數據統計以及熱詞統計還有通知做爲一欄,這樣就是屬於連接一欄,這一欄須要作的:
    A、通知連接、文字展現。
    B、去爬取三大頂會(CVPR,ICCV,ECCV)的論文信息,而且作出統計分析。
    (2)以論文編號、題目、關鍵詞爲輸入的搜索欄做爲一個場景。
    (3)以論文列表輸入的論文信息分析與統計做爲場景。(2)(3)做爲一欄。
    二、導出論文信息做爲一個頁面,將其結果做爲關鍵詞圖譜分析的內容。另外還可以對結果爲屬性分析。故而關鍵詞圖譜分析界面做爲導出論文信息的子頁面。
  • B(Benefits)
    這個平臺的好處就是直擊用戶的需求----對論文的信息統計分析,可以向用戶展現近年來國際的熱門領域和研究方向、學校的熱門領域和研究重點。同時還可以簡略的展現用戶所感興趣的全部論文的簡略信息(論文標題、關鍵詞。摘要),讓用戶可以在短期內篩選出本身所須要的論文及其信息。
  • C(Compettors)
    咱們的競爭優點已經在B中有所說起,那就是可以讓用戶在短期內篩選出本身所須要的論文及其信息,用戶須要作的很簡單,提供一份論文列表就能夠了,或者是用戶本身去挑選本身所感興趣的論文,將其做爲分析統計的內容就能夠了。
  • D(Delivery)
    能夠經過QQ,微信等通信工具進行推廣。

結對過程
在閱讀用戶給出需求後,咱們在草稿上對基本的設計以及結構作了必定的分析並結合原型頁面對需求進行了正常的結構分析(輸入內容、處理、輸出結果)

編程

原型截圖
一、登錄頁面
微信

二、註冊頁面
網絡

三、主頁面
搜索框:可輸入論文編號、題目、關鍵詞,而後在三大頂會爬去相應論文信息。
輸入框:論文列表/會議名稱----此項用於作論文內容分析---添加則能夠將相應論文添加到列表項。
批量導入:用戶能夠將論文標題、連接等內容製成Excel表格,而後以文件形式導入列表
(按鈕---導出論文信息):論文標題、摘要、關鍵詞、原文連接。
(按鈕---選中刪除):對所顯示的論文列表裏面的選中的論文標題進行刪除。
(按鈕---篩選)對論文標題進行信息爬取。
(圖標--星號)用於論文列表的收藏,方便用戶下次的論文信息導入
頁面左邊三個連接:導出的頁面也都是基於三大頂會(CVPR、ICCV、ECCV)的論文信息作出的論文內容篩選(熱詞呈如今不一樣年限內的熱度走向趨勢,國家、學校對論文的錄用狀況分析)。
工具

四、導出論文信息頁面
(按鈕--篩選)對屬性(oral、spotlight、poster)的篩選
連接:對篩選出來的內容的關鍵詞作數據進行統計分析。
post

五、關鍵詞圖譜分析界面
先是以列表形式以從高到低的佔比排序列出關鍵詞的出現佔比,再以扇形給出top10關鍵詞佔比(即top10研究方向),再以條形圖的方式給出top10領域的佔比。
學習

六、主頁面左邊一欄連接(從上到下的順序)測試

  • 三大頂會熱詞走向對比
    搜索引擎

  • 國家對論文的錄用次數對比
    上邊一個表格列出列表論文每一標題論文的總錄用次數。
    下邊一個即點擊論文標題後顯示出來的,即表示每個國家對該論文的錄用次數對比(默認是第一篇,存在點擊事件)
    (均是由高到低的排序)

  • 學校錄用論文及研究重點分析
    左邊表格顯示論文被錄取的次數具體的顯示數目可由客戶選定)
    右邊表格顯示學校的研究重點(具體的顯示數目可由客戶選定)

困難與解決
作爲一個編程不算太好的人,作原型設計的時候,對功能實現的具體作法有必定的侷限性----(不知道這個功能能不能實現,具體的實現方式是什麼)。對此作原型設計會感到畏手畏腳的,由於一旦某個功能以爲不能實現的時候,還須要作出具體的分化。
好比,作議論文列表做爲輸入,導出論文信息的功能處理的時候,考慮了用戶的具體輸入是什麼。如果只有標題,那麼咱們必須實現對頂會的論文作處理,而且存儲在本身的數據庫中,否則,直接爬取信息那麼就感受會出現問題----(可是具體的問題就不知道什麼,可是根據本身的理解應該是這樣的,直接以論文標題做爲輸入去檢索定位論文的第一手內容,而後對其爬取,那是很容易出問題的,甚至沒法實現),對此不清楚這個問題須要在原型設計中怎麼展示出來。
因此問題的解決方法也只能記錄問題的所在,而後留待具體的實現的時候討論方案設計。
因此存在一個問題,作原型設計的時候是否是須要設計師和程序員的相輔相成纔可以設計出更加合理,貼近基於可以實現的原型設計。而後考慮到這,問題的答案已經呼之欲出了----二者的兼顧是十分必要的。只是咱們如今的所學有限,限制住了咱們的實現方式...
出現這種問題的時候,咱們須要記錄問題,在討論實現的可能性,再反饋到原型設計中。

PSP

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