結對成員
031502516 李佳瑩
031502528 蘇媛
[PDF檔案] (http://pan.baidu.com/s/1miOfa5M)
原型設計工具
最先我們是先嘗試了GUI Design Studio，究其原因是我看一些人的評價說是它較為簡單一點。就下載下傳的角度來說它倒是确實不難，但在我們開始在網上尋找它的使用教程和自主鑽研的時候，我才真正地意識到了小馬過河故事的意義所在。小馬在自己下河走之前不會知道河水到底有多深，而我們在親自使用之前也永遠不會明白一個軟體到底适不适合自己。
總之在下完它之後我們一籌莫展了良久，主要問題在于我們的英文水準不夠，無法很好的了解每一個功能和按鍵，而網上又很難找到比較有親和力的教程視訊，是以最後我們選擇換一個工具使用。
這次選用的是Mockplus，是在好友的傾情推薦下開始接觸的。不得不說語言真的是一個巨大的鴻溝，跨越了之後的使用感覺較之前真的是輕松了不少。這款原型設計工具使用前需要先新增賬號，并不是冗雜的舉動，在注冊後會收到官方發來的郵件，裡面有着該工具的使用教程連結，可以說是非常貼心了。将它與先前下的GUI Design Studio做對比的話，個人感覺優勢最大之處是在頁面連結時，Mockplus可以直接用滑鼠連過去，相較起來真的是顯得格外便利。
NABCD模型
- N（Need，需求）
從本次題目中可以看出，我們總共有兩種客戶，一個是普通的，需要加入部門的學生，另一個則是部門裡負責招生的那一部分管理者。
從困擾的現狀中，我們可以看出，學生最大的難題是無法集中地獲得各部門的活動時間，進而導緻了個人的時間安排不暢，平白浪費了時間與精力。是以對于一個剛步入校園，想要加入部門的新生來說，他的需求就主要表現在對各部門資訊的擷取上。
而對于各納新部門的負責人來說，他們手工發放申請表，手工彙總，再人工通知時間資訊，太過混亂，是以需要一種更簡便，更省時省力的資訊處理手段。
- A（Approach，做法）
我們可以建立一個網站，提供一個平台為客戶擷取資訊。
- B（Benefit，好處）
學生可以在上面擷取自己想要的部門資訊，如果有了想要加入的部門，也可以直接點選申請。他們還可以在上面看到自己所面臨的面試和部門活動的時間地點，一目了然，不會出現因為遺忘或者疏忽而導緻時間相碰無法處理的情況。
而負責納新的部門管理者則可以在上面釋出自己部門的簡介，在未來的部門活動中，也可以釋出臨時通知，進而能夠統一告知部員臨時活動等事情的具體資訊。學生可以在上面直接報名，是以負責人也不再需要手工發放宣傳單和報名表。非常直接地在物力人力方面免去了他們很大一部分負擔。
- C（Competitors，競争）
呃，現在的競争對手基本上應該是班裡其他的結對CP 了。要論我方小組的優勢的話，可能就是我們特别情比金堅了，我們将報名的手續最大的簡化。隻需讓學生一次性在個人資訊頁面将基礎資訊填好，報名時就隻要在報名頁面點選報名按鈕即可，無需重複填寫報名表單。
會有這樣的想法，主要是當一個人報名多個部門時，報名表上的很大一部分基礎資訊都是重複的，反複填寫這些資訊很容易令人産生厭倦情緒，這極有可能會提前結束了部分學生探尋适合自己部門的步伐，在納新期過去之後才覺得自己錯過良多，這就很可惜了。嗯，當然，更主要的是，我們設計這個原型系統，最大的目标本就是能夠将這段流程進行簡化，能夠讓使用者少動一點手，總歸是沒有壞處的。
這個做法也可能會出現一點弊端，比如每個部門擷取到的資訊相同，沒有差異性。但這個問題可以很輕易的在面試環節中更一步了解到，是以我們認為，瑕不掩瑜。
- D（Delivery，推廣）
理論上來說，推廣一個用于學生與部門之間的産品，首先要從部門開始入手，部門接受了這個産品，就有了穩定的資訊來源，自然就能吸引新生使用。
結對&照片
我們相性比較好，生肖比較配。
第五次作業———原型設計（結對）
遇到的困難和解決方法
最大的困難就是最開頭不得不更換原型模型工具，前面提過了，這裡就暫不贅述了。
還有就是我們兩人對于題目的了解在初級階段發生了沖突，提出的想法也很有多相異之處。但萬事勝在溝通，我們互相列舉了自己思路的曆程和提出這個想法的理由，在一條條慢慢梳理下達成了共通，也就形成了目前的這個設計。
設計說明
本次設計的項目樹如下圖：
登入界面
- 學生
第五次作業———原型設計（結對）
- 管理者
第五次作業———原型設計（結對）
學生登入
- 首頁
第五次作業———原型設計（結對）
- 部門清單
第五次作業———原型設計（結對）
- 某部門界面
第五次作業———原型設計（結對）
- 學生日程
第五次作業———原型設計（結對）
- 個人資訊
第五次作業———原型設計（結對）
- 我的申請
第五次作業———原型設計（結對）
- 我的社團
第五次作業———原型設計（結對）
管理者登入
- 部門詳情
第五次作業———原型設計（結對）
- 部門納新
第五次作業———原型設計（結對）
- 部門成員
- 臨時通知
第五次作業———原型設計（結對）
PSP表格
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 20 | 15 |
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | 360 | 535 |
| · Analysis | · 需求分析 (包括學習新技術) | 120 | 200 |
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計複審 (和同僚稽核設計文檔) | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 30 | |
| · Coding | · 具體編碼 | 180 | 250 |
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | 55 | |
| Reporting | 報告 | 75 | 78 |
| · Test Report | · 測試報告 | 60 | |
| · Size Measurement | · 計算工作量 | 5 | 3 |
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | 10 | |
| 合計 | 455 | 628 |