課程: 軟件工程1916|W(福州大學)
做業要求: 結對第一次—原型設計(文獻摘要熱詞統計)
結對成員:131601207 陳序展、221600440 鄭曉彪
本次做業目標: 閱讀《構建之法》,針對小櫻瞭解頂會論文研究熱點的需求以結對的形式進行軟件的需求分析以及原型設計,初步體驗兩人合做的需求分析和原型設計過程
原型設計:頂會熱詞統計系統
附件:結對第一次—原型設計(文獻摘要熱詞統計).PDFweb
礙於時間緊促,原型製做工具使用笨拙,在基本分析設計了基本需求的界面和功能的基礎上,一些附加需求的分析和設計都有待完善
基本需求:數據庫
小櫻是一名大三的學生,一直癡迷於吃雞類遊戲,某日聽聞同宿舍的小狼剛和導師去參加了CVPR會議,心裏羨慕不已,便下定決心痛改前非、努力鑽研,但願能在畢業前完成一篇站在時代前沿的優秀論文。但使人苦惱的是,他不知道近幾年頂會的熱門領域和研究方向,根據論文list去一篇一篇查找總結效率又着實過低,因而求助於「軟工實踐互助愛心組織」,但願咱們能幫助他設計一個平臺解決現階段的需求。但願此平臺至少具有如下功能:編程
附加需求:微信
作了需求分析後,咱們繪製了思惟導圖,將需求對應的功能放置到了不一樣的頁面中去app
學術搜索是一個十分具備發展前景的領域,在學術搜索方面,目前市面上有中國知網,百度學術,萬方智搜等一些學術搜索平臺,相比於這些學術搜索平臺,咱們的平臺所具備的優點和劣勢以下:工具
優點
一、目前的學術搜索平臺並不支持批量檢索的功能,而咱們的平臺支持批量檢索的功能,便於用戶一次進行多篇論文的檢索,提升了用戶的檢索效率
二、目前只針對於計算機視覺領域的三大頂會CVPR、ICCV、ECCV,因此搜索結果更具備專業性、精確匹配性
三、界面更加美觀,易於用戶使用操做
四、對於檢索結果,提供了諸如關鍵詞圖譜、柱狀分析圖、折線分析圖、餅狀分析圖等直觀的表現形式,利於用戶使用
五、頂會熱詞提供了頂會近年來TOP10熱詞,便於用戶瞭解當前的學術趨勢post
劣勢
一、相比於其餘學術搜索平臺,咱們的數據庫較小,檢索內容有限
二、UI界面人機交互性不足,缺少美感
三、功能分配尚需改進學習
原型設計工具:墨刀測試
登陸註冊頁:
優化
主頁:
檢索結果頁:
點擊「頂會熱詞」查看頂會熱詞統計分析
批量搜索頁:
點擊「TOP10」進入批量論文分析
困難描述
一、在一開始對於需求有些地方不理解,如對論文列表進行增刪改操做後面有個備註今年、近兩年、近三年是什麼意思
二、咱們對需求在原型設計中的權重安排,對功能在界面上的安排一直難以取捨
三、因爲咱們都是第一次接觸原型設計這個概念,也是第一次使用原型設計工具——墨刀,所以一開始對於墨刀的使用有些不熟悉
解決嘗試
一、經過討論,認爲今年、近兩年、近三年這三個條件能夠做爲篩選項,對論文爬取結果列表進行篩選
二、商量重要需求和通常需求,對重要需求,其功能在原型設計時可能要另外加頁面,而一些通常需求只須要有所表示便可。如本次原型設計中的熱詞分析部分和論文批量處理部分,咱們都安排了另外的頁面;而對國家、學校以及學校研究方向的統計分析,咱們縮放到檢索結果頁中的一個側邊欄,讓用戶能在搜索時看到數據就行了
三、經過查看教程,實際使用,不斷提升使用墨刀進行原型設計的能力
是否解決
一、已解決
二、已解決
三、已解決
經過閱讀《構建之法》一書和此次實際結對完成做業,對於結對編程的概念有所理解,並經過實踐加深了理解,也對原型設計的理念有所瞭解。同時掌握原型設計工具——墨刀的基本使用方法。
131601207 陳序展
我是在軟件工程的第一節課上第一次聽到結對編程這個「新名詞」的,第一時間我就經過百度搜索,瞭解告終對編程的基本概念,很快地就找定了本身的隊友,後來經過閱讀《構建之法》4.5節的內容,對於結對編程的定義有了進一步的理解。在此次的原型設計的過程當中,由於整體設計的時間比較長,因此我與隊友之間「領航員」與「駕駛員」的角色時常互換,在實際的設計過程當中,我深入的體會了這種合做方式的好處,在我進行具體設計的時候,隊友總能夠提出一些我想不到的好點子優化個人設計,而在隊友進行設計的時候,我也能夠提出一些新的想法,不斷地優化咱們的設計。固然咱們在實際的設計過程當中也發現了一些問題,好比一開始咱們可能對一些具體功能只有一些基本的設想,並無制定好詳細的設計方案,致使在設計的過程當中,咱們的設計一改再改,浪費了許多時間,這是咱們須要總結並改進的方面。整體來講,咱們的結對過程仍是比較良好的,咱們都很積極主動的參與任務,並無產生大的分歧,互相均可以積極的聽取對方的建議。固然,除了收穫了對於結對編程的實際體驗,加深了對於結對編程的理解,我也在實際設計的過程當中,掌握了原型設計工具——墨刀的基本使用方法。
221600440 鄭曉彪
經過本次對「小櫻」需求的分析以及文獻摘要熱詞統計原型設計的實踐,我體會了兩人合做,雖然時間只有短短五天,可是天天想着小櫻的需求,想着原型怎麼分配功能,怎麼作的好看、合理,兩我的提出了不少想法也參考了別人的作法。這麼多想法的碰撞很難不和隊友產生矛盾,很幸運,和結對夥伴的結對過程還算順利。就如書中提到的結對過程是一個互相督促的過程,駕駛員和領航員的角色是要時常互換的。由於咱們都很難一眼看透用戶需求,很難一下想到大部分功能,並且長時間緊張工做會使咱們的觀察力和判斷力降低,因此整個過程,我和隊友都是相互分享,有不一樣的想法就多思考,多參考,相互幫助,最後商量出統一的方法來,我想這在以後團隊更多人的合做裏是更爲重要的。不過雖然過程比較順利,可是我也發現了在這過程當中本身的問題:
一、在看到需求的時候對功能設計的思惟不夠發散,多是眼界和設計實踐的侷限所致
二、參考越多本身越不知道作什麼,這也想加,那也想改的,很頭疼
因此,我也很感謝隊友,在結對過程當中能提出個人問題,提出他的想法。
根據《構建之法》2.2節的內容,效能分析是對於程序代碼的分析,因爲咱們的平臺目前還停留於原型設計階段,並無進行效能分析
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 |