結對項目之需求分析與原型設計(選擇和配置設定大學畢設導師)

成員

031402330 吳宇軒

031402327 肖承志

##項目名稱：選擇和配置設定大學畢設導師

項目來源：

大四的學生需要進行大學畢業設計，每個學生都會被配置設定到一個導師進行畢設指導，而每個導師的時間精力有限，隻能指導有限個學生，需要做出一款成品軟體，為導師和學生進行牽線搭橋，盡量讓每個學生可以選到自己心儀畢設方向的導師，每個導師可以選到對自己研究方向有興趣的學生。

項目現狀：

系負責人下發導師候選名單(excel或word形式)給該方向的所有學生，每個學生報五個平行志願送出給年級負責人，年級方向負責人手動收集彙總并發給系負責人。系負責人人工安排算法排序，統一給每個學生配置設定導師。而老師隻有被動配置設定到學生，大多學生也隻能被動配置設定到老師。每個老師對于期望的學生數不同，不能做到滿足各自心願。學生也不太了解老師的課題選擇和研究方向。稀裡糊塗分完的結果，為後續畢設的指導留下很多困擾和隐患。

##需求分析

N(Need,需求):

這個項目的核心需求是将人力從繁瑣的層層收集彙總解脫出來，用更科學合理的選擇算法讓老師和同學們進行雙向選擇，盡量做到每一個老師同學都能選到自己心儀的目标，握手成功！

• 年級負責人需求：可以不用一個個向同學們統計資訊，以防彙總的時候出現錯誤。

  如果能有一個軟體讓同學們自己錄入選擇資訊，就不會産生錯誤啦。

• 系負責人需求：人工安排算法排序，還要盡量滿足更多同學的志願，如果一個導師很多同學選還要按績點進行排序，即使算法best也要花費大量的時間精力還容易造成疏漏。

  如果能用一個軟體将所有同學的選擇資訊導入進行自動排序選擇就輕松多了，還可以添加導師選擇功能，實作雙向選擇。

• 報名學生需求：填了五個導師的名字，雖然是平行志願，但總是希望能由排序更靠前的導師進行畢設指導。還能對可選擇的導師有一個大概的了解，知道他們的研究方向，能由自己感興趣方向的導師進行畢設指導。
• 導師需求：能指導對自己研究方向感興趣的學生或者某方面來說相對其他學生更優秀的學生，讓學生們在畢設中能有更好的成果。

A(Approach,做法）:

• APP可以通過手機等易攜的終端裝置進行操作，我們打算前期先做APP，後期視情況決定需不需要做web端。
• 每個學生以學号為賬戶，導師以職工号為賬戶，進行導師選擇操作。導師會提前對自己所帶學生數量進行設定。
• 每個學生和導師都會有自己的介紹，關于項目實踐、研究興趣方向、專業技能等的履曆，以期在雙向選擇系統中能被自己心儀的對象所看中。（其中研究興趣方向是前期由導師提供，系統生成各個小欄目後由學生選取）。
• 每個導師都會在個人資訊中留下自己的郵箱，可以供學生們進行前期的咨詢聯系。
• 在系統選擇中會給導師一段時間進行對有意向由該導師指導畢設的學生中選取自己心儀的學生，其餘的名額由系統按選取算法進行自動比對選取。

B(Benefit,好處):

• 參考研究所學生的雙向選擇機制，對大學畢設導師選擇系統進行雙向選擇機制安排，讓有意願考研的學生可以提前了解熟悉研究所學生的導師選擇機制。
• 在對導師研究方向有了解、與導師有前期溝通的前提下，讓更多的同學不再是迷茫狀态：不知道自己的導師是誰、研究方向是什麼、自己的畢設課題是否真是有用有價值有情懷。
• 解放了年級負責人和系負責人大量的時間精力，降低了因人工産生錯誤帶來重大不良影響發生的可能性。
• 導師可以選到自己心儀的學生，在志同道合的畢設研究中收獲更多更好的課題成果。

C(Competitors,競争):

• 提供了一個互相了解的平台，可以讓導師和學生們能有所了解而不是在互不相知的情況下陰差陽錯的開始畢設。
• APP樣式簡潔。作為一個服務學生的校園教務軟體，簡潔實用就是它的最好诠釋。這款軟體為的是解決畢設導師選擇問題，盡量讓更多的學生選到自己心儀的導師，更多的導師選到自己心儀的學生。是以它的界面要簡潔，功能要專一，讓人一看就會明白如何操作使用！
• 研究興趣方向的歸類，可以讓學生們在五個志願都無法選上的情況下也能找到志同道合的導師。

D(Delivery,推廣):

• 與學校教務處商議進行捆綁安裝或由其開辟功能跳轉連結（可能需要進行web端的建設）。
• 以“實用、簡潔、空間小”為宣言進行軟體宣傳，一款幾乎不占用存儲空間又必須使用的小巧軟體。
• 在同學間進行前期推廣測試，讓同學們進行軟體評測建議，如果使用者體驗效果良好則能占據先期市場。

##原型設計

###通過對使用者需求的分析和詳細的讨論，我們大緻總結了app要實作的功能，并設計了原型模型。

>所使用的原型模型設計工具：**Axure Rp**

• 結對讨論ING。

• 原型模型的界面結構清單。

• 簡潔的應用首頁和登入界面。

應用首頁的三個選項分别跳轉至學生登入界面/教師登入界面/導師選擇結果查詢界面。

登入界面中輸入使用者名(學号或教師号)和密碼即可登入系統。

學生界面

學生登入至系統後跳轉至學生界面，學生界面下方有三個選項分别為個人資訊/導師資訊/志願選擇，登入後預設先顯示導師資訊界面，左上角為退出系統選項。

• 學生-個人資訊界面。可以檢視個人資訊，進行修改郵箱/密碼/個人介紹的操作。

• 學生-導師資訊界面。清單為各個導師的簡要介紹，點選可跳轉至導師的詳細資訊界面。

• 導師詳細資訊界面。可檢視導師的詳細資訊(研究方向/個人介紹等)。

• 學生-志願選擇界面。可按志願順序填寫五個導師，也可填寫希望方向，綜合考慮後優化導師選擇的滿意度。

教師界面

教師登入至系統後跳轉至教師界面，教師界面下方有三個選項分别為個人資訊/待選學生/已選學生，登入後預設先顯示待選學生界面，左上角為退出系統選項。

• 教師-個人資訊界面。可以檢視個人資訊，進行修改郵箱/密碼/研究方向/個人介紹的操作。

• 教師-待選學生界面。清單為選擇自己的待選學生的簡要介紹，按績點從高到低排序，點選可跳轉至待選學生的詳細資訊界面。

• 待選學生詳細資訊界面。可檢視學生的詳細資訊(郵箱/個人介紹等)。如果覺得滿意可以點選下方的選擇來選擇該學生，同時還給出了目前選擇該學生的導師數作為參考。

• 教師-已選學生界面。可檢視已選擇的學生的簡要介紹，同時給出可繼續選擇的人數。點選跳轉至學生的詳細資訊界面，如果希望取消選擇該學生，可在詳細資訊界面點選下方的取消選擇進行操作。

選擇結果

選擇結果出來後，可在選擇結果界面查詢，查詢角色分為學生/教師/負責人，學生可以檢視自己選中的導師的資訊，教師可以檢視自己選中的學生的資訊，負責人可以檢視所有選擇結果的資訊。

• 

##效能分析

由于我們的産品原型并沒有實際的代碼和成品，無法進行真正的效能分析。而初步預計程式代碼的效能主要在于導師選擇算法以及從資料庫讀取資料的速度上。

• 一個更好的導師選擇算法無疑可以減少很多的程式導師配置設定時間。
• 如果将軟體存儲空間盡可能減少，許多資料就會存儲在伺服器上或直接從教務處讀取，這裡端口的讀取速度也影響着程式的運作速度。

##PSP

PSP
Planning
- Estimate	估計所需要的時間為4周
Development
- Analysis	分析客戶的需求，總結要實作的功能，減少多餘的工作量
- Design Spec	編寫并生成設計文檔
- Design Review	文檔由結對二人共同編輯稽核
- Coding Standard	統一代碼規範和細節
- Design	功能代碼編輯/前端建構/資料庫建立
- Coding	Java
- Code Review	由結對二人互相審查
- Test	功能測試/BUG調試/精簡代碼
Reporting
- Record Time Spent	記錄用時
- Test Report	編寫測試報告/記錄測試遇到的問題和解決方案
- Size Measurement	确定工作量/合理安排時間
- Postmortem	總結結對程式設計的優點和不足
- Process Improvement Plan	編寫改進計劃/更新項目

##預期規劃

我們的方案采用安卓用戶端的方式實作，後期視APP發展情況考慮要不要進行web端的建立。通過Java和Mysql進行APP的基本功能實作，優化使用者體驗，UI的唯一要求就是簡潔明了，能讓使用者一眼就明白該如何操作。因為這是一個有針對性的特殊軟體，使用頻率正常是一年一次，而使用目的也是盡可能滿足導師學生的雙向選擇，因而重點還是在算法的設計，如何用一個盡量簡單快速的算法進行選擇比對。

##小結

原型的設計采用RP進行，因為界面盡量簡潔明了的初始要求在設計原型上省了很多時間精力。但關于學生導師頁面上應有資訊的讨論花費了比較多的時間，而即使是RP上初始架構建構也讓用過墨刀的隊友大呼美工不易。Markdown剛開始使用時還有些生澀，後面習慣了就還好，也讓我們意識到了決定一個軟體的被接受與否除了本身的好壞以外還有一個至關重要的就是前期市場的占領。正如騰訊在尚未建構滿意的情況下投入市場隻為比MSN更快一點，讓使用者熟悉使用習慣，更好的占領市場佔有率。讓使用者在同類型産品之間轉換的成品遠大于讓使用者熟悉一個全新類型的産品。因而對于現在的這個産品我們讨論後的要求就是算法盡量好，推出的速度盡量快人一步，界面盡量簡單明了，以期在同類型的産品中能拔得頭籌。

部落格的PDF版