同學A : 031502630 - 吳松青
同學B : 031502644 - 鄒星
第一次結對作業
本次作業的要求是設計一個方便部門納新與學生選擇部門的app，當然只是原型......剛開始怕要求實現的我們畏首畏尾，總得考慮到后期的實現的困難。最后老師提醒我們不需要實現后，我們也算是大展拳腳，做了個我們兩都還滿意的原型。接下來，就讓我們進入這次作業。
目錄:
一.需求分析 ( N )
1.作業背景
* 1.1.部門方面問題
* 1.2.學生方面問題
一. 需求分析 ( N )
-1.作業背景
>各個部門在開學初占據學校青春廣場有利位置，通過張貼海報、發傳單等形式向學生宣傳；對某個部門感興趣的同學，填寫加入部門申請表交給各部門負責人。各部門負責人通過一種說不清道不明的算法對申請的學生進行人工篩選，人工篩選留下的學生也面臨被淘汰問題。然而現在存在着許多問題（如下），我們很想做這樣一個系統，讓部門選擇的過程能夠信息化起來，讓學生和部門之間可以雙向選擇。 - 1.1. 部門方面問題: - 部門納新人數和面試時間必須事先申報確定； - 部門活動時間包括常規活動時間（如每周三19點-20點）和臨時活動時間，常規活動時間在納新時候就要公布； - 如果一個學生常規部門活動時間請假超過6次，將面臨被淘汰； - 未參加部門面試的學生不能納入部門； - 流程繁瑣復雜，各個部門手工發放申請表，手工收集匯總； - 各個部門之間信息溝通不暢； - 部門在學生申請之前對學生也不了解，稀里糊塗，不可言說，就接收了，導致后續配合存在隱患和困擾。 - 1.2. 學生方面問題: - 大部分新生不能確定自己的興趣點，或者不知道部門是否適合自己； - 對部門情況了解有限； - 學生最多加入5個部門，但是要考慮部門活動時間沖突次數； - 不能及時了解各部門的常規時間沖突情況，而常規部門活動時間請假超過6次，將面臨被淘汰 ；二. 具體做法 ( A )
-
1. 需求分析圖
-
2. 功能
- 2.1. 學生
- 雙登錄界面
- 關鍵字搜索部門 。
- 可查看部門介紹、納新信息以及日常活動，還可以看到前輩的留言哦，可以填寫入部申請。
- 有個特色是有個專門的時間表頁面，可以清楚的知道每天是否有活動，綠色代表有活動，紅色代表活動沖突。
- 內附請假系統，若請假5次后再次請假將會提醒你已經請假5次。
- 消息通知頁面有平時的活動通知以及請假信息是否被批准。
- 個人信息頁面有我的部門（已加入的、待批復的、未面試的），還有請假管理。
- 2.2. 部門
- 能編寫部門的具體信息，還能發布部門活動時的照片；
- 可以設定納新人數、面試地點以及面試須知；
- 可以添加、修改、刪除常規活動信息與臨時活動信息。
- 有個消息通知頁面，可以接收新同學的入部申請與部員的請假請求等。
- 在部門成員頁面可以查看部員信息（包括請假次數），可以將部員踢出，也可以設置部員職位。
- 在學生申請界面可以查看申請的同學的信息與操作是否納入部門。
哈哈！具體還要體驗過才知道啊，以下給出我們的部門幫app原型鏈接：部門幫
三. 產品帶來的好處 ( B )
-
1. 學生
學生
- 消息暢通，了解各部門，可選擇自己喜歡的部門；
- 更加方便的向各部門申請入部；
- 對於部門面試時間和活動時間不會遺漏，可以提早安排自己的行程，避免時間沖突；
- 請假方便；
-
2. 部門
> 部門 - 流程簡單，各個部門無需手工發放申請表，手工收集匯總；。 - 發布納新面試時間時，將提示當前學校在此時間段也同時進行面試的部門，有利於面試時間的更改，盡量減少與其他部門的沖突。 - 自動按照專業歸類申請學生，利於部門首次篩選。 - 考量期的應用，便於部門更好地淘汰部分不積極或者不適合該部門的學生。 - 記錄學生出勤數及參與活動次數，采用積分制度，更好去了解統計部員對部門的貢獻。 - 可更新部門動態，便於部員了解當前部門的活動及近況。
四. 市場競爭分析 ( C )
-
4.2 競爭優劣勢
> 優勢 - 功能較多，針對性強，比較實用。劣勢
- 色彩方面比較單一
五. 推廣 ( D )
*1.面向群體
- 大一新生與部門人員 *2.推廣方式
- 向入學的新生推廣 - 向團委方面推廣以便從上而下的推廣到各部門，再由各部門推廣給學生。六. PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鍾） | 實際耗時（分鍾） |
|---|---|---|---|
| Planning | 計划 | 20 | 20 |
| · Estimate | · 估計這個任務需要多少時間 | 360 | 400 |
| Development | 開發 | ||
| · Analysis | · 需求分析 (包括學習新技術) | 50 | 60 |
| · Design Spec | · 生成設計文檔 | ||
| · Design Review | · 設計復審 (和同事審核設計文檔) | ||
| · Coding Standard | · 代碼規范 (為目前的開發制定合適的規范) | ||
| · Design | · 具體設計 | 120 | 160 |
| · Coding | · 具體編碼 | ||
| · Code Review | · 代碼復審 | ||
| · Test | · 測試（自我測試，修改代碼，提交修改） | ||
| Reporting | 報告 | ||
| · Test Report | · 測試報告 | ||
| · Size Measurement | · 計算工作量 | 5 | 5 |
| · Postmortem & Process Improvement Plan | · 事后總結, 並提出過程改進計划 | 30 | 45 |
| 合計 | 585 | 690 |
七. 總結
-
吳松青-031502630
這次的結對作業的任務我個人感覺還是比較輕松的，因為之前有過設計原型的經驗，所以沒有太大的壓力，但是這次是跟別人一起合作設計原型，肯定需要大家一起商量決定這個設計，之前是自己一個人做，所以想怎么設計就怎么設計。經過這一次的合作，讓我體會了團隊合作的重要性，也讓我獲得團隊合作所帶來的收益。先來說一下這次合作的過程吧，剛開始確定用什么工具與做需求分析是比較順利的，但是總是要考慮自己后期做不做的問題，一直束縛着自己（雖然心里想着應該不會讓兩個人就來完成這東西吧）。最后得到老師肯定的說明之后，可以開始大展拳腳了。但是由於隊友跟自己不在一間宿舍，所以后期的完成品的主題存在着一些差距，所以就不免要花一些時間修改了。說到這里，我還是比較佩服隊友對於這個原型的想法的，我覺得他比我的想法多，所以最終兩者的結合體就由他來完成了（恩，我是很放心的），然后博客就由我來寫。一直合作的是比較愉快的，最終做出來的原型也比我一個人做的好太多了。總得來說，對於這次一起合作完成的作業還是比較滿意的。
-
鄒星-031502644
可以說這是我第一次和別人一起負責一個題目，並一起設計完成一個項目。確實是沒有和別人一起的經驗，一開始的設計討論時，倒也是還好。經過討論便已經分配好了各自的任務，我是負責學生端的那部分。到了這個步驟后，大家便各自回去搞自己負責的部分了。然而卻是導致我們再過了幾天后准備將各部分一起合並時才發現了。兩個人的風格有差別！而且各部分細節的處理差異導致了我們兩個做的很難合並為同一個app，於是沒辦法我只有將兩個人的都進行了修改進行風格上的靠攏和一致。在這部分上也浪費了很多時間。總而言之，第一次結隊可以說是有意外也有收獲。而對項目的總結嘛，也是有很多話想說，本人是第一次接觸設計，所以先是去學習了如何使用工具。然后也莫名的感覺挺好玩的。我們是經歷過那個部門納新的時期的，並且還可以說記憶沒遺忘。所以對其的需求分析也算了解。在確定了不需要考慮實現的時候。我就開始設計學生端了。首先是對部門的了解，學生要加入部門肯定是要對有很多了解的。而這些信息的來源，我覺得就是部門自己的介紹和學長學姐的建議。所以我給部門的詳細那加了一個風采展示環節和前輩留言。還有將消息留言特意做出了一個模塊來。因為我感覺對於雙方而言，相互的消息的即時了解是非常重要的。而在活動時間上，我認為較為是要區分有活動的日期和有活動但是活動有沖突。同時將請假申請放入在查看活動的界面中，個人也認為比較合理吧。其實個人也還有很多想法想去實現來着，但是也想到了一個問題，這個app的功能基本已經達到了，用戶的需求已得到滿足的情況下，如果我才繼續加入一些比較雞肋的功能的話，少且尚可，但是多了的話，只會讓人感覺復雜和難懂。所以也就適當的放棄了。
