原型设计（结对第一次）
結對成員
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個小時。在這期間，我們共同商討了本次的任務和原型系統的核心功能和流程。在周一晚上我們匯總了彼此的工作成果，并加以討論并優化，基本完成了本次作業的要求。
| 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 | · 事后總結, 并提出過程改進計劃 | ||
| 合計 |
轉載于:https://www.cnblogs.com/xiezhe1204/p/7681764.html
總結
以上是生活随笔為你收集整理的原型设计（结对第一次）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： hdu 6200 mustedge mu
- 下一篇： 【题解】 [HEOI2016]排序题解