031402203 陳齊民
031402505 陳少銘
需求分析與原型設計
需求分析
N（Need, 需求）
在分析客戶的現實困擾后，我們總結提煉了以下幾點用戶的痛處所在：
- 收集信息的過程十分繁瑣， 需要班級先收集，后匯總給年級負責人，再匯總給系負責人
- 對於導師不夠了解，沒有導師的相關詳細信息，無法選擇自己感興趣的方向的導師
- 導師對學生也不夠了解，導師不知道學生需要什么幫助，有何興趣愛好，希望往何方向發展
- 傳統的導師選擇操作不便，系負責人只能excel表用某種復雜而說不清道不明的人工排序和算法分配
- 導師分配不平均，某些同學可能被分配到非他五個志願的導師
A（Approach, 做法）
我們決定開發一個安卓客戶端 (其實web端的更好用，但是我們兩個人前端都不是很好..)，對總結的用戶痛楚進行逐一解決，讓選導師和導師選更加方便：
- 學生用學號注冊，登錄后選個五個志願的導師（如果教務處提供API最好了！）
- 查看導師信息，學生可以選擇自己方向的導師，並查看他們的詳細信息
- 填寫自己的專長/興趣/方向，導師篩選時可以查看學生的專長/興趣/方向，是否契合自己的研究方向
- 采用安卓客戶端方式，學生和導師有不同的操作界面，操作簡便 (下拉看原型設計)
- 系負責人不可言說的權利，系負責人可以看到各個導師的學生分配情況，若存在無選中導師的學生，可根據導師的學生數進行適當調整
B (Benefit, 好處)
肯定是好處多多啦：
- 信息收集方便，年級負責人再也不用擔心要收集表格信息了
- 導師學生相互了解，學生：“blablabla，這老師好酷！”，導師：“I want you！”
- 解放系負責人，系負責人：“哈哈哈我終於可以不用手動分配導師了”
- 操作簡單方便，這個APP好酷炫好喜歡
C (Competitors, 競爭對比)
還有那么多結對的弟兄們在做選導師系統，競爭當然大了：
| 平台 | 功能 | 優勢 | 劣勢 | |
|---|---|---|---|---|
| 我們組 | 客戶端（后期加上網頁端） | 導師選擇 | 移動端設計方便 | 使用需要下載 |
| 其他組 | 客戶端 or 網頁端 | 導師選擇 | 網頁端無需下載 | 無電腦時不好操作 |
D (Delivery, 推廣)
推廣感覺現在只能先向身邊的同學推薦使用
原型設計
通過前面的NABCD模型分析之后，我們總結了客戶的需求並且提供可行的優化步驟，以下是我們做出的原型模型：
- 所采用的原型模型設計工具：MockingBot
- Markdown工具：Mou for mac
- APP原型模型：
登錄界面
登錄用戶登錄之后，根據賬號進入不同的入口，學生進入學生頁面，導師進入導師頁面；注冊時學生需要使用自己的學號和身份證進行實名制注冊（教務處提供API就無須注冊了，但是教務處貌似封殺了一切）；以下是注冊界面和登錄界面：
學生端界面
主頁學生主界面為導師選擇界面，學生需要選擇五位導師和自己的教務處總績點，還可在技能特長填寫自己的興趣愛好專長方向等等優勢，無需年級負責人收集表格，只需要學生進行下圖為主頁界面；
導師信息導師信息頁面可以查看學生自己方向的所有導師列表，點進去后可以查看對應導師的基本信息、履歷和研究方向，便於學生根據自己的興趣選擇導師，也可以看到該導師接收的學生數，媽媽再也不用擔心我稀里糊塗一臉蒙逼的選擇導師了，下圖為導師信息界面；
個人信息學生可以個人信息頁面填寫或修改自己的個人基本信息，也可以編輯自己的個人履歷，方便導師的查看，滿滿的履歷導師快選我快選我，下圖為個人信息界面；
設置設置頁面可以設置是否推送中選信息，版本更新提醒，可以檢測最新版本，下圖為設置界面；
導師端界面
主頁導師主頁面為已選該導師的學生列表，列表的順序按照學生的績點降序排列，導師可點擊cell查看對應學生的信息和履歷，可選擇該同學是否為自己的學生，點擊提交則通過學生的導師選擇申請，“I want you！”下圖為主頁界面；
你的學生導師在你的學生頁面可查看自己的學生列表，點擊某學生可查看他的個人詳細信息，通過搜索bar可查找學生，下圖為你的學生界面；
個人信息導師可以在個人信息界面修改自己的信息、履歷和研究方向，方便學生查看，導師也可以設置自己的學生數，學生可在導師信息查看該導師接收的學生數，下圖為個人信息界面；
設置設置頁面可以設置是否推送中選信息，版本更新提醒，可以檢測最新版本，界面與學生端的設置界面相同；
-
(4) PSP
PSP 計划 估計這個任務需要3周時間 開發 需求分析：簡化導師學生雙選的過程，提高導師選擇的效率，減少人工工作量 生成設計文檔：.md文檔 設計復審：隨筆是有兩人共同討論寫成的 代碼規范：代碼格式整齊，變量盡量名詞化，且采用駝峰法 具體設計：界面設計、數據庫設計、代碼邏輯設計等等 具體編碼：Java + PHP 代碼復審：因為是結對編程，所以可以不間斷復審 測試：黑白盒測試 記錄用時 利用課余時間，大概2-3周左右的時間 測試報告 根據黑白盒的測試結果寫測試報告 計算工作量 感覺工作量應該不大，利用課余時間還是足夠的 事后總結 可以邊做邊總結，在碰到問題的時候就記下來，最后總結也不會忘記 過程改進計划 -
(5) 預期規划
我們的方案采用安卓客戶端的方式實現（如果有時間也會實現網頁版），搭建ThinkPHP框架和MySQL數據庫，使用Java+PHP實現；在APP的基本功能實現之后，對UI進行美化，優化用戶體驗，因為學生導師雙向選擇系統只有在特定的時間才會被使用，每年估計就一次吧，所以如果有時間，會在APP功能實現之后，進行網頁版的開發，並盡力做到網頁版的簡潔易用。 -
(6) 小結
以上需求分析和原型設計是在閱讀《構建之法》后結合作業而寫的，兩人討論了許多次，包括客戶端和后台應該如何配合能夠更加輕松地實現功能等，也考慮了許多在開發過程中可能會出現的問題，比如界面美觀、算法優化等問題，求棟哥和助教帶飛，指出方案的不足之處。
//Markdown用了之后才發現真心好用啊，排版也美觀簡潔，看起來特別舒服，就是有一個很難搞的問題，在Mou上排版排的好好的，到博客就出現奇奇怪怪的問題，最要注意的就是空格和回車，多一個或者少一個排版就不對了。。比如上面的456，怎么改都不對
附:
- 博客園的Markdown排版太簡潔了不夠美觀，所以我們組用Mou for mac進行隨筆的md排版，附上隨筆的.md文件 需求分析與原型設計隨筆.MD
- 隨筆的.pdf文件 需求分析與原型設計隨筆.PDF