作者： 031402209 黃偉炜 031402230 張建明
需求分析
N:Need
- 選導師流程複雜不透明.需要班級先收集，後彙總給年級負責人，再彙總給系負責人
- 需要手動收集資料.調整配置設定.浪費時間和精力
- 老師和學生存在被動配置設定.老師無法選擇學生.學生也可能選不到自己想要的老師
- 老師希望控制學生人數
- 學生希望了解老師課題和研究方向
- 老師和學生互相選擇
A:Approach
- 移動端,程式設計在安卓
- 時間制,在規定時間内完成選擇.類似教務處選課系統
- 多輪選擇,類似教務處系統
- 互查資訊,學生老師雙向檢視個人資料
B:Benefit
- 移動端簡單便捷.現在比較适合使用的
- 不必争分奪秒.有充足的時間考慮
- 沒選中下次還可以選擇.實在不行也隻能随機了(這也是沒辦法的事情咯)
- 知己知彼.加深老師和學生的互相了解
C:Competitors
- 千篇一律,都差不多
- 網頁,安卓,ios都差不多
- 這個類似教務處選課.我覺得挺好的
- 安排多次選擇.給學生更多的機會.這是不錯的
- 現在已有的校園應用大使用者量大，它們已經實作了一些學生需要的功能，如選課、查成績等。它們的競争力最強。
D:Delivery
這個估計沒啥好推廣的了，每年用一次。最好作為現在校園應用的補充功能子產品
原型設計
棟哥說不能隊内結對，于是就找到了班上的建明。然後，我們就開始了熱烈的讨論。在幾番他讨論之後，我們确定了需求。于是，開工
- 打草圖
需求分析及原型設計 - 使用
設計Axure Rp
需求分析及原型設計
- 在原型設計方面，我們嘗試了幾款原型開發軟體。其中，Fluid UI、和 墨刀 是網頁應用，比較便捷，但是使用起來比較卡頓。最後決定采用
AxureRp
- 注冊和登陸界面: 因為，本次原型設計和主要功能師實作，學生和導師之間的雙向選擇。這個功能考慮應用時效性，這個應用不适合作為獨立應用開發。最好是，整合到現有的校園應用（
福大助手
福大易班
福大教務通
- 學生端:本着去繁從簡的原則,登入之後的學生界面,有選擇導師的界面.以及對每個老師的資料描述,學生隻需要在規定的時間内選好自己喜歡的導師即可.
- 老師端:本着去繁從簡的原則,登入之後的老師有修改界面.選擇學生界面.以及對每個學生的資料描述老師先填好想要收的學生數量,已經學生選擇導師之後,選擇自己喜歡的學生即可
學生端
需求分析及原型設計
導師端
需求分析及原型設計
效能分析和PSP:
效能分析:
- 對象:移動端程式
- 目标:去繁從簡
- 預測:可能出現的問題就是如何擷取學生老師的資料。以及使用何種算法，來配置設定導師。同時，讓導師也選中滿意的學生。
PSP
計劃
使用 java 語言進行伺服器應用開發不熟悉，預計要四周完成開發開發
- 分析需求。找到學生和老師之間互相選擇的痛點。
- 生成設計文檔
- 設計複審。初次，先讨論定好要實作的功能，做出原型。再對原型進行稽核，對原型進行修改完善
- 代碼規範。主要代碼是在 android 端完成。而且 google android 的代碼規範很優秀。是以，采用 google java 的程式設計規範（風格）
- 具體設計。按照原型設計進行實際編碼開發
- 代碼複審。對開發的代碼進行複審，對代碼進行重構。有利于代碼維護和疊代
- 測試。進行單元測試
記錄用時
記錄流程中每一步的具體用時測試報告
做真實的測試，擷取測試結果并分析總結&改進
完成任務後，對整個過程的遇到的困難和出現困難的原因進行分析和總結。然後，針對每個困難提出改進的計劃。
小結
- 首次設計原型，對原型軟體使用不熟悉。為了盡快實作原型，使用“暴力”`堆各種矩形和圖示的方法，缺少互動效果。還需要深入學習使用
- 最後安利一下，windows 平台下的 markdown 神器 typora
- 作業附件：需求分析及原型設計.pdf