結對名單： 031402224 彭巍 031402233 鄭揚濤
一、一個老師的迫切需求――選擇和配置設定畢設導師之煩惱
選擇和配置設定大學畢設導師的現狀：
系負責人下發導師候選名單(excel或word形式)給該方向的所有學生，每個學生報五個平行志願送出給年級負責人，年級方向負責人在某個截止時間點之前負責彙總該方向所有學生的填報志願，發給系負責人。系負責人通過一種複雜而說不清道不明的人工排序和安排算法，統一給每個學生配置設定導師。人工配置設定的規則現有這些：
1.每個學生最終必須被配置設定到有且僅有一個導師；
2.每個老師最多帶不超過8個學生；
3.某些熱門老師受大多數學生共同選擇而溢出時，考慮學生績點優先；
4.每個老師配置設定的學生數盡可能平均；除非老師主動向系負責人聲明自己帶的學生數希望是0――8中的某個數值或某個區間，那麼盡可能滿足老師的需求；
5.在最後情況下，某些同學可能被配置設定到非他五個志願的老師。 這樣的情況希望越少越好。
現狀的困擾是：流程很傳統複雜繁瑣不透明。過程也很繁瑣，年級負責人手動收集彙總，系負責人手動分發調整。老師隻有被動配置設定到學生。大多學生也隻能被動配置設定到老師。每個老師對于期望的學生數不同，不能做到滿足各自心願。學生也不太了解老師的課題選擇和研究方向。稀裡糊塗，不可言說，就分完了，為後續畢設的指導留下很多困擾和隐患。
二、需求分析（NABCD模型）
1、N（Need，需求）
1、
資訊收集與發放流程複雜。
系負責人需要将導師名單手動下發至學生，然後學生送出的志願要人工逐級向上彙總。為了簡化流程，提高資訊化程度，最好可以有一套系統能夠代替人工操作。
2、
導師的主動權不大。
導師隻能被動的配置設定到學生。如果今年導師由于某些原因不能帶太多的學生，而系裡又強制配置設定一定數量的學生，則造成不必要的困擾。是以，導師在該系統中需要有一定的主動權，比如可以聲明自己所帶的學生數，能夠主動選擇學生等。
3、
學生與導師之間互相不了解。
如果導師在之前是有給自己上過課的，那麼還好說，但是也有相當多的導師是第一次接觸，完全不了解。導師對學生也存在相同的情況。是以，在系統中學生與導師之間應該能互相檢視個人資訊，學生履歷，教師研究方向，聯系方式等等（來源于教務處和學院提供的資訊）。
4、
配置設定方式、流程、結果不透明。
“系負責人通過一種複雜而說不清道不明的人工排序和安排算法，統一給每個學生配置設定導師”，會不會給人一種欽定的感覺...是以，需要将配置設定流程透明化，同時配置設定結束後結果需要進行公示。
2、A（Approach，做法）
我們選擇開發APP用戶端，使用者是學生和老師，使用者是直接生成不用注冊，類似教務處，賬号是學号/工号，密碼是身份證後六位。主要思路類似教務處選課，學生先在某段時間填寫志願（沒到截止日期可以修改），然後老師選擇學生，最後若是還有學生沒有配置設定到導師可以用以前的算法進行配置設定。
學生子產品的功能：
1.學生可以檢視有哪些導師（可以分類檢視），及其個人資訊，并選擇。
2.可以檢視自己選了哪些導師并退選（在截止日期前）。
3.若被某個導師選中則會收到提示消息。
4.編輯個人資訊。
老師子產品功能：
1.導師可以檢視選擇自己的學生及其個人資訊，并選擇。
2.可以檢視自己選中了哪些學生。
3.編輯個人資訊。
3、B（Benefit，好處）
資訊分發與收集實作資訊化。
學生登入系統後，能夠檢視各個方向導師的資訊，填報志願隻需要在APP中勾選即可。無需進行Excel的彙總，減少時間成本和出錯幾率。
提高導師選擇的主動權。
導師能夠在個人資訊中編輯期望的學生數。同時可以檢視有哪些學生選了自己，再根據學生的其他資訊可以決定是否選擇該學生。
實作導師方向的分類索引。
學生可以根據自己的興趣，很友善地選擇适合自己的方向，了解到該方向有哪些導師在做研究。
促進師生之間的了解。
在清單中可以很友善地檢視學生或者導師的資訊。
4、C（Competitors，競争）
各個學校每年都會有學生面臨導師配置設定的問題，是以導師配置設定系統的需求空間還挺大的。
我們的優勢：
移動端APP操作簡單友善。
實作導師方向的分類索引。
學生與導師擷取資訊便利。
我們的劣勢：
APP使用者粘性不強，大學四年隻用一次，用完就解除安裝了。
未提供評價導師功能，無法檢視他人對該導師的看法。
使用者互動、UI等有待改進。
5、D（Delivery，推廣）
推廣的話，可以先安利給數計學院下一屆的學弟學妹試用，有了一定的使用者基礎後，再不斷完善界面、功能，然後逐漸推廣到全校。
三、原型設計
原型模型設計工具：MockingBot（墨刀）
推薦掃描下方二維碼進行線上體驗原型 或 點選我 進行跳轉：
登入子產品
Figure 1. 登入界面
學生子產品
Figure 2. 導師清單
Figure 3. 選擇導師
Figure 4. 已選擇後
Figure 5. 導師詳情
Figure 6. 分類索引
Figure 7. 志願清單
Figure 8. 退選志願
Figure 9. 已退選後
Figure 10. 消息界面
Figure 11. 個人資訊
導師子產品
Figure 12. 學生清單
Figure 13. 學生資訊
Figure 14. 選擇學生
Figure 15. 已選擇後
Figure 16. 中選學生
Figure 17. 教師資訊
結對交流過程
Figure 18. 讨論原型草稿
Figure 19. 設計登入界面
Figure 20. 設計學生首頁
四、效能分析和PSP表格
效能分析
| 流程 | 花費時間 |
|---|---|
| 需求分析（畫原型草稿） | 45min |
| 熟悉原型工具 | 40min |
| 開發原型 | 3.5h |
| 改進完善 | 35min |
| 文檔（部落格） | 3h |
PSP表格
| PSP | Personal Software Process Stages | 計劃時間 |
|---|---|---|
| Planning | 計劃 | 45天 |
| Estimate | 估計這個任務需要多少時間 | |
| Development | 開發 | 30天 |
| Analysis | 需求分析 | 3天 |
| Design Spec | 生成設計文檔 | 1天 |
| Design Review | 設計複審 | |
| Coding Standard | 代碼規範 | |
| Design | 具體設計 | |
| Coding | 具體編碼 | |
| Code Review | 代碼複審 | |
| Test | 測試 | 7天 |
| Reporting | 報告 | |
| Test Report | 測試報告 | |
| Size Measurement | 計算工作量 | |
| Postmortem & Process Improvement Plan | 事後總結, 并提出過程改進計劃 |
五、小結
閱讀完建構之法的相關内容後才意識到一個程式員要關注的事情不僅僅隻有編碼、測試，使用者的需求和體驗同樣重要。之前沒畫過原型圖，畫的過程中才發現把需求變成功能是要考慮很多細節，還要考慮實作的可行性。學習完NABCD模型之後，對需求分析有了初步的了解，并在此次的結對程式設計中進行了實踐。在這次實踐中學到了很多的知識，更重要的是我們知道了一個程式員該如何評估發展自己。
六、附件
本次部落格的PDF版：點選檢視