結對者：031402140李嚴 0314026617林瑞斌
需求分析與原型設計
NABCD模型
N（Need，需求）:
- 收集信息的過程太過繁瑣，有班級總負責人需匯總每一個同學的志愿并填入excel表中，上交年級負責人，年級負責人再將信息通過excel表導入
- 時效太慢，要想完成一次選導師的任務工作，需要收集每一個人的意愿，再將信息通過復雜的算法，盡量照顧到每一個同學的情況下，把導師分配完
- 學生分配不均衡。有的老師可能有5-6，而有的老師就只有3個
- 師生之間互不了解
學生對老師的不了解：只能夠通過學院官方網站以及學長學姐口中得知，只能得知老師的方向以及老師好不好（畢設好不好過），其他幾乎都一概不知
老師對學生的不了解：老師不了解學生的學習狀況以及其能力，只能在分配完之后才得知，原來我分配了幾個學生，都是怎樣的- 志愿提交后就幾乎不能更改。都說了，收集信息的過程太過繁瑣，所以在選擇導師志愿的時候就格外慎重，因為一旦提交了，就幾乎不能更改
A（Approach,方法）:
- 通過老師學生互選的方式，可以大大縮短完整選導師的時間
- 采用安卓客戶端，但起初的話web端的更好用，但由于考慮到選導師只是每年一次，使用次數較少，若在移動端得到用戶的支持，可將其附加到例如福大教務處這樣啊app上
- 師生之間充分了解，老師的信息中添加了一欄，是近三年來畢設課題以及優秀畢設的連接，讓同學更加深刻充分地了解老師的方向，老師也可以充分了解學生的計劃與經歷
- 輪選時間制度，就想學習的選課制度一樣，在一定的時間內學生選擇導師，時間截止后由老師反選，待老師反選完后，再進行第二輪選導師，由未分配到的同學選擇
- 心儀老師選擇，能夠在更小更精確地范圍內選擇導師，而不是大范圍地去篩選老師，除此之外還可以利用篩選來縮小心儀老師的選擇范圍
B（Benefit,好處）:
- 信息獲取更為方便和充實（不用再通過各種小道途徑來了解老師了，咦，生物信息學是什么方向，畢設要做什么？看完老師信息后，奧~我懂了。）
- 時效性更大（就像選課一樣，可以有幾輪選導師的情況，但所花費時間不會太長）
- 規定的時間內可以更換自己的志愿（可能在選導師的那幾天，不知何種原因不喜歡這個老師了，但是卻把ta放在了第一志愿怎么辦，怕什么，我可以改啊）
- 老師可以適當的挑選學生（都跟負責人說了不要那么多學生，怎么還分配了這么多，有這個app，我就有選幾個學生，什么樣學生的權利啦）
- 快捷方便操作簡單（畫面簡潔，易操作，交互性好）
C（Competitors，競爭）：
- 與web之間的競爭：
劣勢：移動端需要下載使用，而web無需下載
優勢：操作簡單快捷方便，在選導師的最后一天，對于有拖延癥晚期的同學，恰巧身邊有沒有電腦，移動端就很好的解決了這個問題
（對于移動+web的隊，我只能說，可以在殺手功能上ko）- 與師生溝通模式的競爭：
劣勢：沒有良好的師生交互
優勢：師生交互只是為了更好地了解老師以ta所研究的方向，只要學生從老師信息中get到他們想要的信息，也就不會有多余的交互
（學生人數>老師人數，在選導師的時學生可以私信老師，那么老師面對眾多學生的詢問，是不是都應該回答呢）
D（Delivery，推廣）
該APP針對的用戶是廣大學生和老師，要做到推廣，擁有用戶，可以先與自己系的負責人安利該app，通過使用后，若獲得一致好評后，可以融入到福大教務通里，畢竟一年只是用一次。
原型設計
原型模型設計工具
AxureRp 8.0
結對照片
登錄界面
由于信息是從教務處導入，所以不需要注冊
學生端----首頁界面
從主頁面點擊查看老師信息，以及篩選老師
學生端----心儀老師界面
學生端----已選擇界面
學生端----個人信息界面
教師端----個人信息界面
教師端----首頁界面
教師端----已選學生界面
效能分析
| 內容 | 需求分析 | 手繪原型草圖+確定方案 | 原型工具的使用 | markdown的使用+文檔 | |
|---|---|---|---|---|---|
| 時間（h） | 1.5 | 1+0.5 | 6 | 3 |
PSP
項目耗時記錄表
| 估計時長 | 需求分析 | 生成設計文檔 | 設計復審 | 代碼規范 | 具體設計 | 具體編碼 | 代碼復審 | 測試 | 測試報告 | 計算工作量 | 事后總結 | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 時間（%） | 6 | 5 | 4 | 3 | 4 | 9 | 45 | 6 | 10 | 3 | 2 | 3 |
計劃
- 估計時長：28天，將近一個月
開發
- 需求分析：找到目前的痛點，在針對用戶需求的基礎上加以創新
- 生成設計文檔：有利于更清晰的了解模塊和界面的銜接，便于編碼
- 設計復審：由兩人共同完成，復審則檢查一些遺漏的細節便可
- 代碼規范:查看代碼規范文檔，并列出我們需要注意的點
- 具體設計:界面設計、數據庫設計等
- 具體編碼：嚴格意義上老說兩個人都是小白，所以編碼上花費時間較多
- 代碼復審：由于采用的結對編程，所以代碼復審在模塊或界面完成后
- 測試：采用黑盒白盒測試和真實的測試，獲取測試結果并分析
報告
- 測試報告:黑盒白盒測試的報告
- 計算工作量：在過程中下來每天都做了哪些工作，從而來計算工作量
- 事后總結：總結在過程中遇到的困難，以及其改正方法和下次避免
小結
剛開始叫我用Markdown的時候一臉懵逼~各種不會感覺就像個小白~還好在隊友的助攻下“勉強”學會了。~感覺這次做的有點慢了，希望下次能抓緊時間，少一點拖延，多一點真誠。早一點吧任務做完~
附件
鏈接：http://pan.baidu.com/s/1dFxAPCP 密碼：tof0
介紹和常用使用方法)
)
