結對學生：031402418 汪培僑
031402618 林宇晨
使用工具：Axure Rp 7.0
PDF連結：百度雲 （超過10M沒法上傳隻能百度雲了） https://pan.baidu.com/s/1c282qoK
一、需求分析(采用NABCD模型)
N (Need)
年級負責人：配置設定負責人：
- 需要向同學收集各種自己選擇志願的資訊，收集麻煩
- 需要通過手動彙總資訊，并送出給相應的配置設定負責人，彙總麻煩
老師：
- 根據年級負責人收集的資訊，進行相應規則的算法排序，配置設定好相應的老師，有時候需要一定人工配置設定，隻是單純的配置設定，沒有導師選擇學生這一個環節
- 有時候處理的不好，可能會導緻一些學生的配置設定不合理（當然這方面比較靠近算法）
學生：
- 隻能是被動聽從配置設定負責人的安排，失去自己選擇學生的權利
- 不能夠控制自己所帶學生的個數，從以往來說，一般都是3個
- 對自己的學生不夠了解，有時候連自己的學生的大體情況都不了解
- 對可選導師的了解不夠詳細，選導師的時候也是迷迷糊糊，比如說是導師的研究方向，導師的選題内容
- 學生聯系導師的方式，也不能夠直接去獲得，比如導師電話，原有情況下，隻能夠通過詢問其他老師，或者不同的方式去獲得，缺少了透明性。
A(Approach)
本次課題我們采用了APP進行對該系統的配置設定
- 登入界面，我們設想是調用教務處登入的接口，進行賬号密碼的比對
- 首先有一個系統推送消息，先通知學生老師開始選擇的時間，然後第一步，由導師先提前登入送出自己本次所選學生人數區間，學生登入填寫自己的相應資料，比如推薦利用，以及畢業方向。
- 然後學生端的導師選擇界面通過導師确定的人數，自動生成可選導師的清單，并且可以通過點選導師的姓名得到導師相應的資訊，進行相應志願的選擇次序，然後選擇送出，到對應截至時間，就無法更改，期間可完成任意次的送出，最新一次的送出覆寫上面的送出。學生最多可以選擇五個志願，最少選擇一個志願。
- 接着就是導師端，對學生進行選擇，導師可以檢視選自己的學生清單，并通過點選學生的姓名進入到學生資訊的頁面，檢視學生的推薦，以及他的基本資訊。導師可以通過這些資訊，對相應同學進行篩選，如果不要則點選X，如果要則點選鈎，然後也是有一個截至時間，期間也可以通過多次送出，最後一次即最終确認，然後這個選擇是對應于自己當初的選擇區間，不能大于最大區間，可小于最大區間。當然期間會出現一種特殊情況，就是多個老師選擇了同一個學生，則通過消息在第二輪選導師之前，講消息發送給學生，由學生自己選擇這些選擇他的導師。
- 這樣第一輪選導師差不多完了。
- 第二輪第三輪第四輪選導師的方式與第一輪選導師的方式一樣。
- 第五輪的時候，還是通過采用送出志願的形勢，不過這次選擇的方式就跟傳統的配置設定方法一樣，如果沒有到自己想要的導師那裡去，隻能通過随機配置設定。
- 上述輪次中，如果在某輪已經配置設定完畢後，則通過系統消息回報，導師配置設定已結束，不在進行下一輪的篩選。
流程圖如下所示
B(Benefit)
- 可以化年級負責人收集的方式為送出，可以直接省去年級負責人這個職位
- 可以更加便捷的去了解導師，以及他們聯系方式，不用在想法設法去找了
- 實作了雙向選擇的機制
- 減少了随機配置設定分到不是自己選擇導師的機率
C(competitors)
- 相比于其他設計者而言，我們原型界面的設計是參考了 MOOC課程APP Coursera的界面風格，扁平化簡單易操作。
- 我們的功能基本上可滿足使用者的需求，但是使用者的滿意度上，是有可以改進的地方，比如對導師進行配置設定時候，導師分類上。
- 加入了消息功能子產品，不必向以往QQ群之類的推送消息，學生和導師即可通過消息子產品進行消息資訊的擷取。
- 相比較與Web端的，我覺得應該是55開，Web端通過網頁檢視，電腦螢幕大，可以對條目看的更加的清楚，日後可整合到教務處的功能内部，而我們APP端的則是适應了目前時代的潮流，可以更加便捷的在何處何地，檢視内部的資訊，日後可以整合到福大教務通，或者西二線上之類的應用裡去。
D(Delivery)
- 首先可以在我們周邊的同學進行試用，如果好用的話，整合到福大教務通離去，然後可以推薦給周圍學校的人，然後可以收獲一定的利潤。
二、原型設計
第一步
首先我們進行需求的讨論，并粗略的畫了幾張手畫圖
雙方美術都很差，有很大進步空間
第二步
用原型工具Axure Rp 7.0進行我們界面的展示
我們界面大小采用了720*1280的螢幕
我們經過一起對界面标準進行了一定的統一，以及交換制作
一、首先二話不說一來肯定是登入界面
可以根據你是老師還是學生，選擇對應的賬号密碼進行登入。
二、導師端界面： （用操作步驟進行描述）
1.人數選擇：首先是導師首先确定本次要收的人數，可以按兩個數字，表示自己選擇的區間。
2.導師資料的修改：即展示給學生看的資訊。在第一輪選導師之前送出
3.學生選擇界面：對選擇自己的學生，進行選擇，打勾則表示需要，打叉則表示不要該學生。選學生中
4.檢視學生資訊的界面：通過點選上述選擇學生的學生姓名可以連結到該學生界面。
5.檢視學生界面：檢視已經是自己學生的界面，清單中都是自己的學生。每輪選導師後會更新。
6.消息界面：即定期傳遞給導師的資訊，即第幾輪選課開始，還有自己的注意事項。
二、學生端界面： （用操作步驟進行描述）
1.自我推薦界面：首先學生先進行自我推薦資訊的填寫，友善導師對自己的了解
2.選擇導師界面：即選導師開始的時候，進行的選擇，可通過下拉框，選擇對應的志願編号
3.老師資訊的檢視，點選上述的老師可以連結到老師對應的界面中去，友善了解老師
4.檢視自己導師界面：當已經選上導師後，可以在該界面顯示自己老師的資訊
5.學生消息推送界面：可進行一些資訊的公布，比如第幾輪選課開始了之類的東西，以及上述所提到，多個老師同時選了同一個學生的話，也可以通過該界面，向學生進行提示
三、PSP
| PSP | |
| 計劃 | 估計需要三周的時間 |
| 開發 | 需求分析：實作導師與學生之間的雙向選擇，增強導師和學生之間的了解 |
| 生成設計文檔：通過攥寫的随筆生成PDF | |
| 設計複審：兩個人一起交流，讓文檔設計更加趨于完善 | |
| 代碼規範：條例清楚，寫好注釋，以及方法名字，變量名要易于了解他是用于幹什麼的 | |
| 具體設計：資料庫設計，界面UI設計，代碼邏輯設計 | |
| 具體編碼：JAVA | |
| 代碼複審：完成一個功能部分，複審一次 | |
| 測試：每一個部分功能完成後，反複測試 | |
| 記錄用時 | 大概三周時間把 |
| 測試報告 | 把所有可能性的測試都寫出來 |
| 計算工作量 | 感覺對于兩個安卓小白來說這工作量一開始感覺不是一般的大 |
| 事後總結 | 還沒有完成。。。 |
| 提供過程改進過程 |
四、效能分析
| 前期需求分析，功能過程讨論，手繪圖各自表達自己的觀點 | 3H |
| 用Axure RP設計界面 | 5H |
| 後期攥寫随筆 | 4H |
前期讨論的時候比較集中時間，到設計原型界面的時候，時間用的有點零散，導緻有時候銜接不上，上次做的有些細節，這次沒記住，我覺得以後要集中精力，找個時間連續的做下去，不能零零散散，随筆寫的相對較慢，也是有參考了其他同學的文檔風格。
五、感想
1、本次實驗作業，我們兩個初步了解了團隊合作的重要性，剛開始我們還嘗試着分開各自做自己端配置設定的任務，後面發現後面兩個人所做的界面有點不相容，雖然之前有具體讨論定義了标準，但是經驗還是告訴我們，還是得面對面的交流工作才能得到想要的結果。
2、還有就是有一些細節還是要全方位的考慮，中間的時候就是突然想到某些問題，然後中間一直加一直改，導緻完成效率可能會有點慢。
3、還是就是對Axure RP的使用上，筆者還是第一次使用這個軟體，主要是通過隊友的幫助，（隊友之前有制作的經驗）于是摸爬滾打也慢慢學習了這個軟體的皮毛之處，還有一些小圖示的擷取道路。詳情見此網站：http://www.iconfont.cn/collections
4、還有就是對建構之法NABCD模型的了解，我們明白了，做一個軟體的動機，以及全面了解自己産品的優略，才是一個合格的團隊需要考慮的方方面面。
5、還有就是一個考慮，我們兩個還是一個安卓小白，雖然有了想法，但是如何把它實作出來還是一個任重道遠的事情。