031402304 陳燊
031401433 張斯巍
一、需求分析（NABCD模型）
1、N（Need，需求）
- 師生互選，改變導師被動分配學生的局面
- 每個學生分配到預想的導師，避免分配了志願以外的導師的情況出現
- 學生可以了解到所有導師的課題和研究方向
- 導師可以設定自己想要的學生數
- 導師所分配到的學生數盡可能平均
- 志願填寫和導師的學生數設置均可在系統里完成
- 系統可根據志願情況以及導師需求，通過一定算法得出最后的分配結果
2、A（Approach，做法）
導師選擇每個學生大學四年只需做一次，固開發成單獨的一個APP不是很理智的選擇，我們小組采用的做法是開發一個基於Android端的導師選擇系統，然后整合進現有的APP比如福大易班、福大教務通、福大助手等。這樣在開發過程中便可以專注於主要功能模塊的設計，而不用浪費精力在邊邊角角的界面上。
導師選擇系統大致的運行流程如下：
-
學生和導師在第一次登錄系統時便要完善個人信息，進行實名認證。特別要完善其對應的專業技能興趣或則課題研究方向，系統將自動這些信息進行匹配，為學生計算出每個導師的推薦度，便於學生更有目的性得進行選擇；
-
學生登錄系統，在規定期限內填寫並提交五個志願的導師；
-
導師登錄系統，在學生列表界面查看相應的學生信息，並選擇自己想要的學生；
-
所有導師操作完畢之后，分配算法如下：
-
學生只有被一名導師所接受，將直接分配
-
多名導師選擇同一學生，該學生將被分配給志願優先級高的導師
-
剩余學生按照績點進行排序，並依次檢索其志願，若對應志願的導師已分配的學生數未滿其設定值，將直接進行分配；
-
將導師按照已分配學生數升序排序，剩余學生依次分配給對應導師，以求盡可能讓所有導師的學生數平均分布；
-
算法運行結束，導師分配完畢。
-
-
學生和導師登錄導師選擇系統，查看最終的分配結果，並聯系其對應的導師或學生
3、B（Benefit，好處）
- 改變被動分配的局面，讓每個導師參與學生的選擇
- 推薦度的設置讓學生選擇導師時更理性化，更具指導性
- 導師分配結果大致符合學生和導師的預期
- 學生信息以及導師信息透明化，方便彼此的了解以及溝通
- 大大簡化了年級負責人以及系負責人繁瑣復雜的人工分配
- 每名導師所分配到的學生數量盡可能平均
- 互聯網正在移動化，基於Android端的系統便於用戶下載，實時查看導師信息和分配結果
- 學習成績好的學生有更大機會分配到理想的導師，以此鼓勵學生努力學習
4、C（Competitors，競爭）
- 目前學校的導師分配大都采用人工排序分配的做法，尚無成熟的系統可供使用，市場競爭小
- 潛在競爭對手可視為目前參加軟工實踐的學生，其中不乏有擁有豐富項目經驗的優秀碼農，他們全都在對“導師分配”這塊大蛋糕垂涎欲滴
5、D（Delivery，推廣）
- 當原型系統被采納之后，立馬投入精力進行開發
- 通過博客以及軟工課程進行初期的推廣，預期讓所有修讀軟工的學生了解到該系統，並從學生角度出發期望得到建設性的意見
- 通過郵箱或則當面交談，盡可能向學院所有導師推廣這一個系統，並從中汲取到更為專業、更全面的建議並加以改進
二、結對過程
我和我的對友在之前便有過合作的經歷，我有過一定的Android開發經驗，而對友對前端的掌握也很好，故作業發布后不久我們便結對了。在整個導師選擇系統的設計過程中，我主要是負責畫原型，隊友則是進行初期的草稿以及文檔的完善。結對讓我們效率更為高效，短短幾天時間便完成了作業。
三、原型設計
原型設計工具：Axure rp 7.0
學生端
-
主頁界面——擁有志願填寫、導師信息、個人信息、結果查詢四個功能模塊；
-
個人信息——每名學生均要進行實名認證，並完善自己的個人信息，尤其專業興趣。這些信息在導師選擇學生的時候將會起到重要的作用。
-
志願填寫——學生可以在這個界面填寫自己的志願信息，這些信息將在導師選擇學生時起到關鍵性的作用；另外，在規定期限截止之前，學生可以任意修改志願信息；
-
結果查詢——在規定期限之后，導師選擇系統根據算法分配導師成功。每名學生均可在結果查詢界面查詢到自己的導師以及相同導師的同學，並通過上面的聯系方式互相取得聯系，更有利於之后畢設工作的指導進行。
-
導師信息——導師信息界面可以根據推薦度、研究方向、學生數等進行搜索排序，而每一個導師都會根據學生以及導師的興趣方向自動計算出一個推薦值，可供學生更加理性得進行導師的選擇；
-
導師簡介界面有着每一位導師完整的資料以及聯系方式，學生可以通過聯系方式與心儀的導師事先取得溝通，更有利於之后的互選成功率。
導師端
- 主頁界面——擁有學生列表、個人信息、結果查詢等三個界面。
- 學生列表——擁有待選學生和已選學生兩個界面。學生填報志願完成后，在待選學生界面，每位導師均可查看選中自己的學生信息，並決定是否接受。當學生被導師給選中之后，相應信息會傳遞到已選學生界面，並在后台進行相應數據得更新，讓分配算法的運行更具准確性。而在已選學生界面，導師亦可通過側滑刪除的方法，篩掉先前已接 受的學生。
-
個人信息——導師可以在這個界面完善自己的個人信息，設定想要的學生數量以及研究方向，這些信息都將為學生選擇時提供關鍵的指導作用。
-
結果查詢——在規定期限之后，導師選擇系統根據算法分配導師成功。每位均可在結果查詢界面查詢到自己的學生，並通過上面的聯系方式互相取得聯系，更有利於之后畢設工作的指導進行。
四、效能分析
| 內容 | 時長 |
|---|---|
| 需求分析 | 1H |
| 導師分配流程設計 | 2H |
| 手繪原型草圖 | 3H |
| 用Axure RP進行原型設計 | 6H |
| 用MD進行文檔編寫 | 4H |
| 系統后期完善 | 1H |
因為客戶的需求都比較明確，且自身也經歷過導師選擇，所以前期的需求分析還是比較明朗的，而導師分配流程則是和對友在互相激烈的辯論出得出來的。整個導師分配系統流程確定后，較為頭痛得便是原型的設計，我們在稿紙上畫了好多版的原型之后，才最終確定了如上圖所示的系統。之后便開始原型設計和文檔的編寫。
整個過程大致用了17個小時，基本都是集中在兩三天之內，工作連續緊湊，目的性強，期間也參考了許多其他同學的想法。整體的效率還是蠻高的。
五、PSP
| PSP | |
|---|---|
| 計划 | 預估時長為一個月左右 |
| 開發 | 需求分析：師生互選，系統后台自動完成導師分配，減少人工工作量 |
| 生成設計文檔：.md文檔 | |
| 設計復審：多次審核，共同討論，確保原型的正確性和完整性 | |
| 代碼規范：大小駝峰命名法；杜絕中文命名；適當采用單詞縮寫；見名知意 | |
| 具體設計：數據庫設計、接口設計、界面編寫、邏輯跳轉等 | |
| 具體編碼：Android、JavaWeb、PHP | |
| 代碼復審：在開發過程中不斷對系統進行完善修改 | |
| 測試：單元測試、黑白盒測試、BUG修正 | |
| 測試報告 | 利用測試結果進行測試報告的編寫 |
| 工作量計算 | 預估服務器端的任務比較艱巨，需要實時更新信息，並運行分配算法給出最終的分配結果；Android端因為有過開發經驗，界面之間的邏輯也較為簡單，工作量較小 |
| 事后總結 | 暫無 |
| 過程改進 | 暫無 |
六、總結
導師選擇是每個學生大學必將面臨的問題，在幾個月之前我們也完成了自己導師的選擇，但是整個選擇過程就如客戶需求所述一樣，高度不透明，繁瑣復雜，分配結果也很難做到讓每個人都滿意。因此，開發一個透明化、智能化的導師選擇系統是時勢所趨，這次軟工作業正好也給了我們一個時機去認真思考這個問題並努力解決。
在整個系統的設計過程中，結對的高效率得到了充分的提現，思想的碰撞讓我們迅速得到的系統的大致分配流程，而各自的開發經驗讓我們對原型的設計以及文檔的編寫也是得心應手。互取其長，互補其短，我們在短短兩天的時間內便完成了原型系統的設計。期間對Axure RP軟件的使用以及項目的開發流程有了更深層次的理解。
雖然文檔以至尾聲，但我們並未將其認定為此次作業的結束，我們期待的是專屬於我們的第三次作業的出現。斯是陋室，惟吾德馨。希望我們的原型系統能夠得到您的認可！