原型設計（結對第一次）

結對成員

170320075 解哲
170327078 張合勝

PDF文件

https://files.cnblogs.com/files/xiezhe1204/%E5%8E%9F%E5%9E%8B1.pdf

學生會部門納新的現狀與改善方向

　　現有的部門納新都是以紙質表單爲基礎的。這樣作的好處是內容正式，條理清晰，可是缺點也是顯而易見的。例如，信息彙總不及時，不許確，沒法直觀的判斷各個部門間的活動安排狀況，信息發佈不及時，信息獲取渠道少，檔案丟失率高等。

　　上述一些缺點是目前傳統辦公中比較廣泛的現象。而採用數字化的處理流程和數字化的管理方法就可以比較好的保持信息的完整性和時效性，從而提升學生會納新的效率和對學生會部門成員管理的效率，同時使考勤評價數字化，精確化。

　　本系統總體架構以下所示：

|---學生會
            |---A部門
                |---申請入會
                    |---申請成功
                    |---申請失敗
                |---請假
                    |---請假成功
            |---B部門
            ...

• 1 N（Need）需求

  　　本系統能夠解決用戶面臨的流程繁瑣問題。尤爲是現有流程中關於考勤和活動時間衝突的斷定和處理等費時費力的工做均可以經過本系統快速準確的完成。相應的，爲了知足流程儘量的簡單，且不產生多餘的數據。在申請人填寫報表前無需登錄，系統只須要經過申請人填寫報表的惟一學號來區別用戶。在後續篩選完申請人以後，再要求入圍學生完善信息。這樣作的好處是簡單化註冊流程，提升申請人的積極性。另外一方面，這樣作使得系統儲存更少的多餘數據，並減小系統的複雜度。
  　　新生申請入會時，不須要登陸，直接進入x部門填寫我的信息後提交。

　　學生會主界面：

　　A部門主界面：

　　填報我的信息頁面：

• 2 A（Approach）作法

  　　用戶主要的擔憂在於不熟悉新系統的流程和對舊流程的依賴。咱們的申請處理系統提供給申請人免登陸的申請方式。能夠提供給用戶更便捷的流程，減小申請中由於註冊問題帶來的混亂。在申請入部時，咱們拒絕或警告申請人對於不一樣部門中活動時間相同的同時申請。在後續流程----考勤中，咱們經過用戶頁面實時反應給部員請假次數。
  　　先申請部門不與已申請的其餘部門例會時間衝突則提交成功，不然失敗
  　　提交我的信息成功頁面：
  

　　提交我的信息失敗頁面：

　　申請請假頁面：

• 3 B（Benefit）好處

  　　本系統爲用戶帶來數字化的申請流程，簡化了傳統流程中的彙總所需的工做量，並對部員的考勤進行數字化的管理，使得部員對自身學生會參與程度有直觀的理解，督促部員參與學生會。對於部門負責人，能夠橫向的對比本部部員的出勤狀況，增強對本部的管理效率。因爲申請人申請失敗以後的數據是無用的，再者爲了簡化申請人的申請流程，採用無登錄填寫信息，提升申請效率。
  　　成爲學生會成員以後，須要登陸來獲取更多權限：
  

• 4 C（Competitors）競爭

  　　管理系統的使用如今已經很是的廣泛了，而如何讓用戶快速的接受系統便成爲一種增強競爭力的重要手段。因爲本系統面向的用戶是學生會，因此是一種小型的管理系統，且流程相對簡單。而本隊的優點在於有快捷的申請流程，實時的信息展現。而在其餘傳統系統中存在的諸如的申請人處理，用戶信息展現等方面本系統也有相關功能。而咱們的劣勢在於部門種類的維護和申請人的信息的修改尚未涉及到，咱們主要考慮到的是這些流程或者功能是非核心的，能夠在後續維護中逐步完善。

• 5 D（Delivery）推廣：

  　　咱們的產品擁有簡單易懂的流程，方便的使用環境，而且咱們提供詳盡的用戶文檔來幫助用戶更好的來理解和使用此係統。使用網頁訪問方式，用戶只需登錄特定網站即可完成一切操做。無需安裝，無需關心配置。使用網頁訪問方式，咱們能夠得到比客戶端系統更普遍的推廣途徑，以求得到更多的用戶，更普遍的應用範圍。

• 討論原型設計：

  
  

• 效能分析：

  這次工做的目標是設計出系統原型，我與結對同窗共同參與完成了系統的原型設計工做，在這一過程當中，咱們經過QQ進行了屢次交流，發現經過文字交流效率低下，因而在週一上午進行了一次面談，大約持續了2個小時。在這期間，咱們共同商討了本次的任務和原型系統的核心功能和流程。在週一夜咱們彙總了彼此的工做成果，並加以討論並優化，基本完成了本次做業的要求。

PSP2.1	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	30	20
· Estimate	· 估計這個任務須要多少時間	30	20
Development	開發
· Analysis	· 需求分析 (包括學習新技術)	120	150
· Design Spec	· 生成設計文檔	60	100
· Design Review	· 設計複審 (和同事審覈設計文檔)	60	60
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)
· Design	· 具體設計	100	120
· Coding	· 具體編碼
· Code Review	· 代碼複審
· Test	· 測試（自我測試，修改代碼，提交修改）
Reporting	報告
· Test Report	· 測試報告
· Size Measurement	· 計算工做量
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃
合計