一、結對成員
| 姓名 | 學号 | 班級 |
|---|---|---|
| 程一飛 | 031502608 | K班 |
| 周元 | 051503223 |
二、原型設計工具的選擇
1、原因與過程
因為對原型設計并不熟悉，最初我們按照作業上所寫的幾個設計工具一個個幾乎全都下載下傳過，想選擇一個操作比較簡單的工具，但是具體的感覺都差不多。後來經人推薦，我們發現原來還有很多網頁版的設計工具。在ProcessOn和"墨刀"之間，我們選擇了墨刀，因為他的使用更為簡單，而且更為專業。
2、原型圖檔
首頁
學生登入界面
完善資料
申請部門（點選【部門×】出現部門簡介）
部門簡介
部門登入界面
釋出活動
釋出納新
檢視申請
3、照片
三、NABCD模型分析
1、N（Need，需求）：
本次結對作業對現狀描述如下：
各個部門在開學初占據學校青春廣場有利位置，通過張貼海報、發傳單等形式向學生宣傳；對某個部門感興趣的同學，填寫加入部門申請表交給各部門負責人。各部門負責人通過一種說不清道不明的算法對申請的學生進行人工篩選，人工篩選留下的學生也面臨被淘汰問題。篩選和淘汰的規則如下：
- 部門納新人數和面試時間必須事先申報确定；
- 部門活動時間包括正常活動時間（如每周三19點-20點）和臨時活動時間，正常活動時間在納新時候就要公布；
- 如果一個學生正常部門活動時間請假超過6次，将面臨被淘汰；
- 學生最多加入5個部門，但是要考慮部門活動時間沖突次數；
未參加部門面試的學生不能納入部門。
現狀困擾的是：流程繁瑣複雜，各個部門手工發放申請表，手工收集彙總，各個部門之間資訊溝通不暢，導緻不少學生加入幾個部門後，由于活動時間沖突而被淘汰，浪費時間和精力。學生在加入部門前對部門的情況了解有限；部門在學生申請之前對學生也不了解，稀裡糊塗，不可言說，就接收了，導緻後續配合存在隐患和困擾。
-----引自第五次作業---原型設計(結對)
從描述中可以看出，現狀中最突出的沖突就在于各個部門之間以及部門與學生之間的資訊溝通不暢，由此而導緻了活動時間沖突、學生和部門之間互相的不了解這樣較為嚴重的問題。
此外，篩選和淘汰的機制十分繁雜，靠人工來每次确定的話，對于部門的管理也是一個比較大的難題。部門手工發放和收集彙總申請表，也會浪費很多的人力物力。
2、A(Approach，做法)
我們打算采用B/S模式，通過一個部門和學生都可以登入和操作的網站，将學生和部門的資訊透明化，以此來解決二者之間資訊溝通不暢的主要問題，同時加強互相之間的了解。
網站中分别以部門和學生的身份登入，将會有不同的功能供他們選擇。部門的主要功能有發放和回收彙總申請表、篩選和淘汰部員、公布活動時間并提醒部員等等。學生的主要功能有申請部門面試、檢視通知、申請請假。
3、B(Benefit，好處)
首先，我們采取的B/S模式能夠實作不同的人員，從不同的地點，以不同的接入方式通路和操作共同的資料。不論使用者使用的是何種裝置和作業系統，均可通過作業系統友善和快速的進行所需要的操作。
通過B/S的操作方式，将人工發放申請表、請假等需求搬到網絡上，也能減少部門的人力物力消耗，使同學們不會浪費太多的時間和精力。
4、C(Competitors，競争)
我們的優點主要在于以浏覽器為基礎的跨平台性，系統界面盡力保持簡單易用。
劣勢主要在于相對與一些移動端app，我們的使用者界面不夠華麗，缺少一些賞心悅目的動畫效果；在一些網絡不好的地方，通過網頁不能獲得任何内容，而移動端app卻可以依舊顯示一些常用的功能。
5、D(Delivery，推廣)
- 我們的首要推廣目标應該是學校裡大量的社團，可以采用上門推廣的方式，教他們了解并學會使用該産品，讓他們了解該産品将會在"百團大戰"中帶來的周遊，吸引他們在接下來的納新中使用該産品。
- 在開學的時候，我門也可以制作海報，張貼在各大校園裡，或者制作二位碼，在一些餐廳上進行印刷粘貼，以友善使用者的了解和使用。當我們吸引足夠的學生使用者将資訊注冊到網站的時候，也将會吸引更多社團的使用，以此來達到良性循環。
4、PSP
| PSP | 結對作業 | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 10 | 5 |
| · Estimate | · 估計這個任務需要多少時間 | ||
| Development | 開發 | 250 | 330 |
| · Analysis | · 需求分析 (包括學習新技術) | 60 | |
| · Design Spec | · 生成設計文檔 | 30 | |
| · Design Review | · 設計複審 (和同僚稽核設計文檔) | ||
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 120 | 240 |
| · Coding | · 具體編碼 | ||
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | 20 | |
| Reporting | 報告 | 75 | 90 |
| · Test Report | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | 15 | |
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | ||
| 合計 | 335 | 555 |
學習進度條
| 第N周 | 新增代碼(行) | 累計代碼(行) | 本周學習耗時(小時) | 累計學習耗時(小時) | 重要成長 |
|---|---|---|---|---|---|
| 150 | 48 | 了解了軟體工程的一般方法，學會用工程的視角看待項目 | |||
| 1 | 7 | 55 | 原型設計、合作探讨、複習課程 |
附：PDF:PDF