結對名單：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，好處）

1、信息分發與收集實現信息化。學生登錄系統后，能夠查看各個方向導師的信息，填報志愿只需要在APP中勾選即可。無需進行Excel的匯總，減少時間成本和出錯幾率。
2、提高導師選擇的主動權。導師能夠在個人信息中編輯期望的學生數。同時可以查看有哪些學生選了自己，再根據學生的其他信息可以決定是否選擇該學生。
3、實現導師方向的分類索引。學生可以根據自己的興趣，很方便地選擇適合自己的方向，了解到該方向有哪些導師在做研究。
4、促進師生之間的了解。在列表中可以很方便地查看學生或者導師的信息。

---

4、C（Competitors，競爭）

各個學校每年都會有學生面臨導師分配的問題，因此導師分配系統的需求空間還挺大的。

我們的優勢：
1、移動端APP操作簡單方便。
2、實現導師方向的分類索引。
3、學生與導師獲取信息便利。

我們的劣勢：
1、APP用戶粘性不強，本科四年只用一次，用完就卸載了。
2、未提供評價導師功能，無法查看他人對該導師的看法。
3、用戶交互、UI等有待改進。

---

5、D（Delivery，推廣）

推廣的話，可以先安利給數計學院下一屆的學弟學妹試用，有了一定的用戶基礎后，再不斷完善界面、功能，然后逐步推廣到全校。

三、原型設計

原型模型設計工具：MockingBot（墨刀）

推薦掃描下方二維碼進行在線體驗原型 或 點擊我 進行跳轉：

登錄模塊

Figure 1. 登錄界面

學生模塊

1.學生可以查看有哪些導師（可以分類查看），及其個人信息，并選擇。

Figure 2. 導師列表???????????????????????????? Figure 3. 選擇導師???????????????????????????? Figure 4. 已選擇后

Figure 5. 導師詳情???????????????????????????? Figure 6. 分類索引

2.可以查看自己選了哪些導師并退選（在截止日期前）。

Figure 7. 志愿列表???????????????????????????? Figure 8. 退選志愿???????????????????????????? Figure 9. 已退選后

3.若被某個導師選中則會收到提示消息。

Figure 10. 消息界面

4.編輯個人信息。

Figure 11. 個人信息

導師模塊

1.導師可以查看選擇自己的學生及其個人信息，并選擇。

Figure 12. 學生列表???????????????????????????? Figure 13. 學生信息

Figure 14. 選擇學生???????????????????????????? Figure 15. 已選擇后

2.可以查看自己選中了哪些學生。

Figure 16. 中選學生

3.編輯個人信息。

Figure 17. 教師信息

結對交流過程

Figure 18. 討論原型草稿

Figure 19. 設計登錄界面

Figure 20. 設計學生首頁

四、效能分析和PSP表格

效能分析

流程花費時間

需求分析（畫原型草稿）	45min
熟悉原型工具	40min
開發原型	3.5h
改進完善	35min
文檔（博客）	3h

PSP表格

PSPPersonal Software Process Stages計劃時間

Planning	計劃	45天
Estimate	估計這個任務需要多少時間	45天
Development	開發	30天
Analysis	需求分析	3天
Design Spec	生成設計文檔	1天
Design Review	設計復審	1天
Coding Standard	代碼規范	1天
Design	具體設計	3天
Coding	具體編碼	30天
Code Review	代碼復審	3天
Test	測試	7天
Reporting	報告	1天
Test Report	測試報告	1天
Size Measurement	計算工作量	1天
Postmortem & Process Improvement Plan	事后總結, 并提出過程改進計劃	1天

五、小結

閱讀完構建之法的相關內容后才意識到一個程序員要關注的事情不僅僅只有編碼、測試，用戶的需求和體驗同樣重要。之前沒畫過原型圖，畫的過程中才發現把需求變成功能是要考慮很多細節，還要考慮實現的可行性。學習完NABCD模型之后，對需求分析有了初步的了解，并在此次的結對編程中進行了實踐。在這次實踐中學到了很多的知識，更重要的是我們知道了一個程序員該如何評估發展自己。

六、附件

本次博客的PDF版：點擊查看

轉載于:https://www.cnblogs.com/vvxyz/p/5882995.html

總結

以上是生活随笔為你收集整理的结对项目之需求分析与原型设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。