做業二——結對項目之需求分析與原型模型設計

成員：031302337 My blog   031302340 Her blog

1、方案簡述

客戶的困擾是開課報課的繁瑣，繁瑣的根源即是郵件羣收發，須要人工覈對未反饋的教師，對他們發郵件催收，以及最終人工彙總表格。因而咱們的想法是能夠不限於郵件這個形式，經過手機APP將用戶分爲普通教師和彙總負責人。

1. 羣發郵件：彙總負責人設定開課計劃週期，確認發佈後，就向普通教師發送推送消息。
2. 羣收郵件：普通教師在收到推送消息後，登錄APP在選課頁面經過下拉列表直接選擇本身想要選擇的課程，並完成起訖週數和備註等內容。確認後可查看結果，經過可實時修改和刪除當前選課記錄。同時可在選課頁面屢次選擇課程。
3. 催收郵件：彙總負責人可實時查看當前已提交人數和爲提交人數，經過催收按鈕向未提交的教師發送催收消息。
4. 彙總表格：彙總負責人可實時查看選課結果，並將其生成Excel本地文件，在本地的相應程序中打開運行，同時也可將生成的表格發送至本身的郵箱。

NABCD模型的說明

• Need： 《構建之法》中提到對於需求，「咱們要充分了解用戶的痛苦，他們對已有軟件、服務不滿意的地方。」很巧的是，咱們的組員在催收郵件，彙總表格這件事上也算是半個用戶。班級工做中或多或少涉及到催收各類信息以及彙總的工做，因而深刻這「半個用戶」，她告訴咱們的是「手動彙總表格太繁瑣了，失誤率高，容易遺漏或是重疊。」因而咱們選擇了一鍵生成表格，以此來幫助用戶解決痛苦。
• Approach: 目前不少同窗都打算將這一需求採用app實現，咱們組也是。可是咱們的app，不只能夠實現教師的選課需求以及負責人的催收匯總，同時在查看當前狀態中，也能夠看到當前彙總的表格，這樣能夠實時的關注表格的彙總狀況，便於對後期安排的估計。最後彙總完成後，能夠經過表格預覽界面，將彙總好的表格發送給本身，便於使用電腦瀏覽最終結果，以及開展後期規劃。
• Benefit: 當能夠有更方便的方式完成一件事時，是沒有人願意繞遠路的。移動APP所帶來的好處首推的就是方便。相對於回到家打開電腦去完成一個表格再發出去，用手指在手機屏幕選擇按確認要簡單得多。固然有人會說在手機上也能收發郵件，但咱們想相對於操做表格，咱們的APP是更便捷的。
• Competitors: 據瞭解，部分小組打算用web形式實現。使用web當然比app更加明瞭。但app帶給用戶更多便利，用戶能更加快捷的完成操做，無需過多輸入，及文件下載，發送等操做，而且負責人能夠實時查看選課狀況。
• Delivery: 咱們但願經過有學生工做的同窗，向他們推薦咱們的app，並經過他們將咱們的app推薦到輔導員和老師那裏。最後經過老師或輔導員向學院申請試用咱們的app進行選課，並根據反饋，完善軟件。

2、原型模型

Axure RP Pro 7.0

• 總體流程圖
  
  爲各個頁面編號：
  1.登錄頁面；2.編輯頁面；
  3.普通教師主頁面；4.開始選課；5.選課結果；
  6.負責人主頁面；7.開課計劃；8.當前狀態；9.查看結果；10.表格預覽

• Part1.登錄界面及編輯界面
  
  頁面說明：
  編號1.登錄頁面：普通教師與負責人共用一個登錄頁面，當前不考慮註冊頁面，即用戶名採用教工號，相似教務系統無需註冊。
  編號2.編輯頁面：當編號1頁面中點擊username文本框或password文本框就調整至此頁面。

• Part2.普通教師頁面模塊
  
  頁面說明：
  編號3.普通教師主頁面：普通教工在頁面1完成編輯點擊登錄後跳轉到此界面。點擊「開始選課」跳轉至編號4頁面；點擊「選課結果」跳轉至編號5頁面；點擊「新郵件」（圖中的（1）表示當前有一封未讀郵件），跳轉至外部連接，在瀏覽器中打開當前用戶的郵箱；點擊「退出登陸」即退出當前帳戶跳轉回編號1頁面。
  編號4.開始選課頁面：課程名稱欄選擇本身想要選擇的課程，一個教師可在該頁面進行多門課程的選擇；選定課程後自動顯示該課程相應的學分和學時；選擇起訖週數；對特殊要求再備註欄進行備註；點擊「提交」跳轉至選課結果頁面。
  編號5.選課結果頁面：點擊「修改」，跳轉至編號4頁面進行修改；（但此時編號4頁面的課程名稱這欄已肯定）點擊「刪除」，即刪除當前這門課程的選課信息；點擊「返回」，跳轉回編號3。

• Part2.負責人頁面模塊
  
  頁面說明：
  編號6.負責人主頁面：負責人在頁面1完成編輯點擊登錄後跳轉到此界面。點擊「開課計劃」跳轉至編號7頁面；點擊「當前狀態」跳轉至編號8頁面；點擊「查看結果「跳轉至編號9頁面；點擊「退出登陸」即退出當前帳戶跳轉回編號1頁面。
  編號7.開課計劃頁面：該頁面爲負責人肯定選課時間的頁面。點擊」確認「，即確認當前選課週期設定。（相應的彈窗後期設定）點擊」當前狀態「跳轉至編號8。
  
  頁面說明：
  編號8.當前狀態頁面：點擊「催收」可對未提交教師發送郵件催收；點擊「查看結果」跳轉至編碼9頁面。
  編號9.查看結果頁面：負責人在當前查看選課結果，在課程名稱欄選擇相應課程，學分和學時就自動識別課程顯示；在任課教師欄能夠查看當前選擇該門課程的教師名單，選定某個教師後，開始週數，結束週數和備註欄就鎖定顯示該老師的相關信息；同時也可經過設置開始週數與結束週數來查看在這個週期有哪些老師選了課。點擊」表格預覽「頁面跳轉至編號10；點擊頁面左上角<，返回前一個頁面即編號6。
  編號10.預覽表格頁面：點擊「查看本地文件」將自動Excel表格在本地經過相應其餘程序查看；點擊「發送至郵箱」可將Excel表格發送至負責人郵箱；點擊「返回主菜單」跳轉至編碼6頁面。

解決方案預期規劃

1. 前期學習：熟悉開發該app所須要的工具和相關算法，語言。
2. 界面：開始編程實現各個頁面。
3. 溝通：將實現的界面與客戶進行初步的溝通，根據客戶需求，並優化各個功能的實現方式。
4. 功能實現：開始對功能分塊並編程實現，最後整合。
5. 再次溝通：對開發好的雛形進行調試，（對於測試，咱們但願在編程的過程當中進行階段測試，便於及時修正方案）並與用戶再次溝通，儘可能知足用戶需求。
6. 完善：對軟件進行最後的完善，爭取在限定時間內完成項目。
7. 維護：對軟件進行後期維護。

Ps：以上是咱們的基本規劃構想，鑑於小組的兩人都是初次接觸APP的開發，對於Android的開發也缺少經驗，在這個項目咱們的目標是完成兩個主要功能。前期分別接手一個功能邊學習邊實現，後期兩人共同對功能進行改進和完善。

3、結對過程

上圖爲進行討論原型模型的過程

上圖爲進行討論NABCD模型的過程

4、PDF隨筆附加

做業二——需求分析

5、我的心得體會

總得來講，過程比想象要艱辛，成果和想象有差距。在許多繁瑣的事情上花費了很多時間，大概是處女座的強迫症。截界面圖的時候也截出了好幾個版本。從一開始的需求分析，到使用Axure，以及NABCD模型還有PDF的生成，都有一些心得。     首先，瞭解需求的過程當中，不該該僅停留在固定的思惟當中。以此次的需求分析爲例，一開始我是把本身侷限在郵件這個形式上的。可是還好隊友給了我一個新的思路，解開困頓。     其次，在使用Axure的過程當中，也在糾結是否是應該花不少心思把界面作的吸引人。後來仍是選擇了很簡潔的方式。一方面，在axure.com.cn上的教程中瞭解到原型模型是爲了更好的向客戶展現功能，太過花哨的界面可能反而喧賓奪主，忽略重點；固然還有更重要的一點就是咱們的能力有限，並無前端和UI經驗。但在使用Axure的過程當中，我以爲本身對於UI和前端的興趣較大，但願之後能往此方向發展。     第三，NABCD模型，反覆閱讀了《構建之法》的相關章節，在Approach和Delivery上花了不少時間仍是想不到如何表達準確，但願在後期項目進行中能更明確這兩方面。     第四，PDF一開始原本打算寫完後直接用博客導出工具導出PDF，可是使用了CSDN的相關工具後發現效果不夠好。因而最後仍是選擇了用word從新排版生成PDF。     第五，此次個人搭檔是以前多門實踐課的搭檔。配合應該算是比較默契，可是對於這類的實踐項目咱們仍是第一次，仍然存在一些問題，例如分工不夠明確，角色定位不清晰。但願從此次的做業中吸收教訓，互相指正，在接下來的編程環節將以上這些問題改進。