格式描述
- 課程名稱:軟體工程1916|W(福州大學)
- 作業要求:結對第一次—原型設計
- 結對學號:221600408_蔡鴻鍵 | 221600409_蔡森林
- 作業目標:學習使用NABCD模型,模擬使用者需求和使用工具設計模擬軟體原型。
- 作業格式描述:該部落格首段
- 作業完成工具: Mindmaster & 墨刀
- 部落格編輯器: MARKDOWN
- 結對照片: 正文
- 效能分析與PSP:正文
- PDF附件:已上傳
作業目錄
1.格式描述
2.NABCD模型
3.原型設計
4.結對討論過程
5.效能分析與PSP
6.困難與解決
7.心得與總結
8.PDF以及花絮
作業正文
1.NABCD模型
NEED
- 需求來源:小櫻不知道不知道近幾年頂會的熱門領域和研究方向,根據論文list去一篇一篇查詢總結效率又著實太低
- 關鍵詞:“效率,頂會,熱點論文”;
- 以功能分析需求
- 使用者可給定論文列表 ;
- 通過論文列表,爬取論文的題目、摘要、關鍵詞、原文連結;
- 可對論文列表進行增刪改操作(今年、近兩年、近三年);
- 對爬取的資訊進行結構化處理,分析top10個熱門領域或熱門研究方向 ;
- 可對論文屬性(oral、spotlight、poster)進行篩選及分析;
- 形成如關鍵詞圖譜之類直觀的檢視方式;
- 可進行論文檢索,當使用者輸入論文編號、題目、關鍵詞等基本資訊,分析返回相關的paper、source code、homepage等資訊;
- 可對多年間、不同頂會的熱詞呈現熱度走勢對比(這裡將範疇限定在計算機視覺的三大頂會CVPR、ICCV、ECCV內)。
- 可進行資料統計,例如每個國家錄用文章的分析、每個學校錄用文章的分析、哪個學校哪方面的研究方向比較強等.
- 使用者可給定論文列表 ;
- 以使用者角度分析需求
- 使用者
- 檢索 (題目、摘要...)
- 收藏 (自定義列表、增刪改查...)
- 結構化(篩選分析、視覺化圖譜...)
- 管理員
- 操作(賬號、文章...)
- 統計資料(熱度、關鍵詞、引用...)
- 使用者
- 我們使用MindMaster將筆記草稿轉為思維導圖。
Approach
- 以 WEB 為平臺,WEB 平臺優點:良好的互動體驗 良好的前後端工作分離模式
- 檢索方式
- 題目
- 關鍵詞
- 領域
- 時間
- 熱度
- 引用
- 會議
- 檢索方法
- 精確匹配(關鍵詞完全匹配)
- 模糊匹配(關鍵詞近視匹配)
- 公式匹配
- 收藏
- 使用者點選互動式按鈕進行收藏
- 對收藏論文進行增刪查
- 新增書籤
- 整合“我的筆記”
- 結構化
- 用圖表直觀顯示資料
- 論文對比(對比論文的引用量,發表影響力等)
- 進行資料統計,例如每個國家錄用文章的分析、每個學校錄用文章的分析、哪個學校哪方面的研究方向比較強等。
- 管理論文
- 下載(批量、傳送郵件)
- 上傳 (通過網站、傳送郵件)
- 刪除
- 修改(論文資訊)
- 統計
- 圖示直觀化
- 使用者點選次數最多的熱度關鍵詞
- 對多年間、不同頂會的熱詞呈現熱度走勢對比
- Top10熱門分析
Benefit(以效率為主)
- 讓使用者易上手
- B/S 框架 平臺無關性
- 熱詞、圖表,資料直觀易懂
- 隨時隨地上傳下載(手機、電腦、 平板)
- 自定義收藏
- 方便摘取相關文章
- 書籤:將有用資訊摘取到筆記中,生成"我的筆記"。
- 讓使用者易上手
Competitors
- 優勢:
- 跨平臺
- 隨時隨地
- 對資料進行分析,統計最近最熱方向以及預測估計未來方向
- 功能多樣性
- 劣勢:
- 使用論文的版權難處理
- 大量資料維護不變
- 優勢:
Delivery
- 社交平臺 (公眾號、推送)
- 會議網頁,論文庫網頁,圖書館網頁
- 向個學校的老師和學生推薦
2.原型設計
墨刀連結
階段一
- 根據討論得出的需求分析,大致擬定產品的基本功能。
- 從使用者角度上詳細制定規劃。
- 分工完成各模組的大致草圖。
階段二
- 互相交流各模組的遇到的問題,協商解決。
- 借鑑其他優秀的UI設計。
- 初定介面草圖。
階段三
- 通過墨刀工具進行相關模組的設計。
- 討論並對原型進行調整和優化。
- 實現原型的基本功能。
介面設計
登入介面
論文搜尋介面
熱詞搜尋介面
論文列表介面
收藏夾介面
折線圖介面
條形圖介面
熱詞圖介面
結對討論過程
與3月4日(星期一)組成小組。過程如下
- 分析問題需求,提取關鍵字,使用NABCD模型分析問題,生成草稿
- 使用瞭解MINDMASASTER和 墨刀工具
- 進行模型創作,分析討論使用者需求和體驗
- 優化模型,生成部落格
- 結對照片
4.效能分析與PSP
效能分析
目前還沒生產出軟體例項,經我們估計資料庫訪問語句和伺服器的訪問壓力是比較耗費資源和耗時最多的,應該對此進行優化,如:
- 伺服器:
- 使用記憶體資料庫(僅對熱詞,訪問量較高的文章)
- 增加快取
- 選擇合適的IO模型
- ...
- 資料庫:
- 對查詢進行優化,要儘量避免全表掃描
- 對於多張大資料量的表JOIN,要先分頁再JOIN,否則邏輯讀會很高,效能很差。
- ...
PSP
PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分 鍾) |
Planning | 計劃 | ||
• Estimate | • 估計這個任務需要多少時間 | 180 | 350 |
Development | 開發 | ||
• Analysis | • 需求分析 (包括學習新技術) | 60 | 150 |
• Design Spec | • ⽣生成設計⽂文件 | 30 | 40 |
• Design Review | • 設計複審 | 20 | 10 |
• Coding Standard | • 程式碼規範 (為目前的開發制定合適的規範) | 20 | 20 |
• Design | • 具體設計 | 120 | 250 |
• Coding | • 具體編碼 | 120* | 250* |
• Code Review | • 程式碼複審 | 20 | 10 |
• Test | • 測試(自我測試,修改程式碼,提交修改) | 20 | 20 |
Reporting | 報告 | ||
• Test Repor | • 測試報告 | 30 | 15 |
• Size Measurement | • 計算工作量 | 15 | 10 |
• Postmortem & Process Improvement Plan | • 事後總結, 並提出過程改進計劃 | 30 | 25 |
合計 | 435 | 800 |
5.困難與解決
- D:每個人設計想法不同
A:求同存異,取其優者
- D:工具的使用不便
A:只能多看說明多使用
- D:設計藝術細胞短缺
A:多看參考精美UI設計
- D:分開來做各種部分
A:多交流多討論,向對方提供合理的建議
6.心得與總結
蔡鴻鍵
以往我們程式設計時都是一股腦使勁寫,想到什麼寫什麼,就像在希爾頓的屋子裡那個外國人一樣,會寫中文缺不理解中文的意思。通過此次任務,我明白了程式設計只是很小的一個方面,要賦予軟體生命絕對不能機械生硬的把程式碼從一邊搬運到另一邊。要去了解需求,體會使用者,把軟體帶入到我們生活中,以對人的態度對軟體,也就是對使用者的尊重。但我還是會有一些疑惑,我們這種的方法挺好的,但是不是所有公司都在使用這種方法(計劃),如果未來遇上了某種公司不認真地對待軟體設計,把程式設計師只當成程式碼生產機器,我們應該怎麼辦呢?
蔡森林
通過這次的原型設計,讓我受益匪淺。以往我並不把需求分析當做一回事,覺得大概就好,但是當我們互相討論時,我發現不能只是通過自己的角度看待問題,有時候需要聽取別人的意見。自己考慮問題時,難免會出現考慮不周全等問題,與人交流討論,互相求同存異,更能解決問題。還有就是,通過原型設計,我學會了如何使用墨刀這款工具,這是我第一次使用這樣的工具設計介面,對於我以後的UI設計還是很有幫助的。儘管當中難免會碰到難以解決的問題,但對於我而言都是一種鍛鍊。當設計原型時,我發現,有個大致的草稿圖,對於後期的UI設計能提高很好的開發效率,當然,有時候我們也需要去借鑑一些優秀的UI模板,不僅可以從中體會一些好看的UI設計,而且能讓自己更好的借鑑經驗。總的來說,原型設計的實驗,於我獲益多多。
總結
這次任務看似比較輕鬆,沒有程式設計任務。實際上分析設計和合作才是我們需要鍛鍊的,作為一個大學生,在大學的課程都是在學習程式設計,很少學習分析設計,從上學期的UML才算是軟體設計技術的初略門道,作為軟體設計者來說,使用者需求才是我們最關心的。我們必須站在使用者角度考慮問題。還有合作,在未來工作的時候,自己單幹的幾乎很少,都是大家一起分工搭配,我覺得合作中,資訊與信任是最重要的。在工作中,資訊必須平等流通,否則會導致設計或程式碼對接失敗,成為木桶的短板。信任為合作的核心,有著事倍功半的效果。
7. PDF文件以及花絮
草稿圖
結對第一次—原型設計PDF