17-小澤澤 2018/9/21 1:02:49
作業連結
隊友連結
項目以及pdf的百度雲連結
【 Need——需求】
- 随着計算機的迅速發展，頂會的論文層出不窮，小狼想要通過一篇篇的論文查找，從這麼多的論文中了解當下研究的熱門領域和方向着實不容易，論文數量如此之多，一篇一篇查找效率着實低下，而且浪費人力和物力。
- 從以上的分析可以看出，使用者能希望能有這麼一個平台，能通過掃描論文list，完成自動分析，得出相關的資料，迅速的掌握近幾年頂會的熱門領域和研究方向。
- 需求細化
- 能通過掃描使用者給定的論文list爬取相對應的論文題目、摘要、原文連結，并且帶有篩選功能。對所爬取的資訊能進行資料分析，得出使用者感興趣的資料。
- 純論文檢索，使用者隻需輸入相關論文的詞條（比如作者，編号，題目）就能爬取到完整的論文，分析傳回相關的paper、source code、homepage等資訊
- 熱度分析與資料統計。該平台可以自動根據頂會的所有論文進行資料分析，得出當下的熱度走勢，也可對各大高校的論文引用率進行分析
【Approach——做法】
- 該平台應用于Web端，針對于以上的需求，我們做了如下的方案：
- 針對需求1，使用者隻需給定論文list，平台就能完成自動掃描，通過分析得出資料
- 針對需求2，使用者給定詞條，就能擷取到相應的完整論文和相關資訊。
- 針對需求3，平台可以完成對所有頂會論文的周遊，分析出使用者感興趣的資訊（比如熱詞走勢，各大高校的比較）
- 根據實際情況，我們還添加了一些小的功能，比如使用者可以把自己喜歡的論文加入我的list，可以參與論文的評論等等。
【 Benefit——好處】
- 使用該平台進行論文搜尋，能夠：
- 減少一篇一篇查找時浪費的人力和物力
- 可以更加快速高效的擷取當下的熱門領域和研究方向
- 能較準确系統的進行資料分析（比如熱度分析），避免采樣的單一性（比如使用者如果隻搜尋某一方向的論文，所分析的也隻是該方向的資料）
- 能對大量的論文資訊進行一個整合
- 待平台穩定後将進行完善，擴充更多的功能。
【Competitors——競争】
- 平台界面參照了各大網站的排版，界面美觀簡潔。功能齊全，使用者操作簡便。
- 了解使用者的相關痛點，減少了使用者所要花費的時間和精力，在這個平台上，使用者可以獲得歸屬感，與一群志同道合的人一起交流，獲得更多的經驗和成就。
- 衆多的論文檢索網站并沒有提供自動熱詞分析的功能，也不能分析每個國家錄用文章的分析、每個學校錄用文章的分析、哪個學校哪方面的研究方向比較強等
- 該平台的内容具有針對性，主要就是三大頂會的所有論文，減少使用者盲目的搜尋。
- 該平台提供了論文管理的功能，對論文有較好的分類，使用者可以收藏自己感興趣的論文，友善使用者再次閱讀。
【Delivery——推廣】
- 推廣初階段，針對年級的同學進行小規模的推行，收集回報的資訊，進行平台的修繕，随着平台的更新，使用的人數會越來越多的。
- 待有了一定的群衆基礎後，可争取校方相關管理部門支援，可通過校園微網誌，校園首頁進行宣傳，争取讓更多的同學了解并使用我們的産品。
- 在實作較大規模的應用之後，不斷地更新産品，擴充産品的功能，使得産品能夠适用于更多的群衆。
【我們的結對故事】
蔡文斌的話：确認過眼神，你是對的人，有時候就是這麼的驚喜！！！我們兩個人平時就是玩的比較好的，他又是被我“坑了”，才選的這門軟工實踐課，都是一條船上的，相依為命啊，555！！
黃澤的話：蔡文斌是一個成績優秀的學生，上個學期在他們方向排名第一，是以我覺得跟着他混總沒錯。通過這次結對項目，我明白了他不僅是一個優秀的制作者，更是一個優秀的合作者:他可以在深夜我要和他進行讨論分析時，放下自己手頭上的工作（他是班長兼新生班導）耐心的聽我講解并提出自己的建議和想法；他也可以在我制作界面時陪在我的旁邊适當的說出自己的想法。雖然我們這次作業可能做的不是特别優秀，但是我相信收獲這一個隊友才是最好的結果。
這是淩晨的時候我們進行初次讨論時的照片：
這是我們進行設計時畫的草圖，非常的抽象：
【設計說明】
主要架構圖：
登入界面（掃碼真的有驚喜）
使用者注冊界面：
首頁（為了友善使用者直接将文本搜尋功能添加上去了）
長文本要這樣子檢索（按那個小電腦）
全論文檢索界面（可進行論文檢索，當使用者輸入論文編号、題目、作者等基本資訊，分析傳回相關的paper、source code、homepage等資訊）
論文分析界面（可對多年間、不同頂會的熱詞呈現熱度走勢對比，可進行資料統計，例如每個國家錄用文章的分析、每個學校錄用文章的分析、哪個學校哪方面的研究方向比較強等）
我的論文清單界面（使用者可給定論文清單，可對爬取的資訊進行結構化處理，分析top10個熱門領域或熱門研究方向）
【PSP】
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
| Planning | 計劃 | 90 | 120 |
| •Estimate | •估計這個任務需要多少時間 | 500 | 730 |
| Development | 開發 | 40 | 30 |
| •Analysis | •需求分析 (包括學習新技術) | 150 | 200 |
| •Design Spec | •生成設計文檔 | 20 | |
| •Design Review | •設計複審 | 15 | |
| •Coding Standard | •代碼規範(為目前的開發制定合适的規範) | 10 | |
| •Design | •具體設計 | ||
| •Coding | •具體編碼 | 300 | |
| •Code Review | •代碼複審 | ||
| •Test | •測試（自我測試，修改代碼，送出修改） | ||
| Reporting | 報告 | ||
| •Test Repor | •測試報告 | ||
| •Size Measurement | •計算工作量 | ||
| •Postmortem & Process Improvement Plan | •事後總結, 并提出過程改進計劃 | ||
| 合計 | 580 |
【遇到的問題及解決方法】
-
遇到的問題：
1.原型設計的時候，在設計功能時出現了不一樣的意見，兩個人的審美可能不太一樣，導緻在排版的上出現了分歧。
2.在使用Mockplus進行原型的實際設計時，對Mockplus這個軟體的不熟悉，導緻耗費了一定的時間在了解這個軟體上面。
3.大量繁瑣的重複拖拽工作經常讓我們崩潰，是以我明白了計算機工作者需要保持良好的心态
-
解決的方法
1.拉個旁觀者，少數服從多數。（簡單暴力）
2.百度找教程，學習相關的技術，争取最短的時間内熟悉相關的操作。
3.忍着，養成比較優良的心态，我相信以後會遇到更讓人心煩的東西
【學習進度條】
| 第N周 | 本周學習消耗時（小時） | 累計學習消耗時（小時） | 重要成長 |
| 3 | 5 | 8 | 通過閱讀《建構之法》，了解了要開發一個網站的大緻流程，從最開始的需求分析到原型設計再到最後的實作 |
【功能完善可能】
- 猜你喜歡。每周生成你這本周的論文檢索周報，猜測你的個人喜好，并推薦與此相關的論文。
- 點贊評論，撰寫評論功能的完善
【心得體會】
- 這次是我們兩個人第一次動手設計一個網站原型，從最初的排版到實際的規劃設計，都遇到了很多問題，兩個人也在産生分歧和統一意見兩種狀态中切換，進而體會到有一個好隊友的重要性，（俗話說，不怕神一樣的對手，就怕豬一樣的對友，幸好）這次的作業體會最大的就是合作的樂趣，以前做作業大都是單打獨鬥的，很少與人交流自己的想法，這也為後面的團隊作業打下基礎吧，學會與别人合作，達到1+1>2的效果。
- 設計一個網站的原型或者是一個APP的界面真心不容易，如何能在第一時間吸引使用者的眼球是大有學問的，還需要慢慢的學習。