結對成員：
[張旗 031502243](http://www.cnblogs.com/neveslalala/)
[周琪文 031502642](http://www.cnblogs.com/qiwenzhou/)
需求分析 （NABCD模型）
N （Need）
本軟體意圖建立在大學中，學生管理的部門，社團和學生群體之間的資訊交流平台，主要是解決在大學新生入學後，在部門和社團納新活動的推廣、宣傳和管理。比起傳統的方式，例如“發宣傳單”，“掃樓”，“廣場納新”等，更加節約時間和人工。
普通學生在使用了軟體之後，能夠避免盲目加入社團部門和不知道加入什麼社團部門的處境。社團或部門的成員使用軟體之後，能更便捷地管理現有成員，安排活動，并在納新面對新生時，取得新生的基本資訊，去掉這其中的成本。
A （Approach）
建立一個基于學生資訊的平台，在平台之上，新生可以浏覽、了解各個部門與社團，而且可以向其提出自己的問題，完成送出面試、活動安排等動作，而社團管理人員能初步了解新生個人資訊。
使用Android來編寫程式，通過和教務系統的相連，導入新生的資訊，新生可直接使用身份證号等方式登入。在軟體中，設定部門或社團的首頁來實作對自身的介紹等功能。
B（Benefit）
做到這些，使用者至于要一台智能安卓手機。後期可推廣到iOS平台。
C（Competition）
在福大範圍内沒有類似的軟體和平台，雖然有着像超級課程表中超級社團的子產品，但推廣程度低，功能也不夠針對。
D（Delivery）
我們會和老師溝通，就像福大教務通一樣，作為學校推廣的軟體之一，畢竟是面向整個福州大學的同學的軟體。功能完善之後，就像新生推廣（比如說18級大一學生）。由于時間關系和我們的能力有限，我們的産品可能還知識個雛形，我們以後會繼續對它進行改善，期待新的完美産品面世。
原型系統
app名稱：選我
頁面：44個頁面
模型内容：
模型登陸後，主要分為四個部分，分别是：首頁、部門、日程安排、個人設定。每一個部分都有信箱功能，可以實作接收與發送部門與聯系人的消息，例如收到部門面試與開會等消息，如需請假也可以回複與請假相關事宜。
首頁：
1. 通過輪播圖展示社團和部門的風采；
2. 通知每一位學生一些重要的事件，比如說社聯納新事件地點等；
3. 從首頁直接進入我的部門，可以實作對部門的管理與參與部門的讨論。
- 所有的部門都有一個首頁，首頁按照文章的方式展現自己部門的特色，同時想要詢問關于部門資訊的學生可以在文章下方留言，有助于學生們全面了解社團，而不是稀裡糊塗加入了自己不熟悉的社團。同時每一個部門的首頁都可以一鍵申請，實作線上申請部門的功能。
- 我的部門有兩部分，一部分是我管理的社團，一部分是我參與的社團。
- 我管理的社團（此模型為院·實踐外聯部（副部長）為例），可以實作功能如下：
- 進入首頁：進入部門文章首頁，浏覽與編輯已經釋出的文章。
- 釋出日程：可以釋出日程給所有部員，例如：面試時間地點、開會時間地點等等。同時在 日程安排 上自動生成日程，如有部員沖突，則會提示有多少部員沖突，實作防止日程沖突功能。
- 申請資訊：可以浏覽同學們從網上報名的資訊，可以通過申請與拒絕申請，實作線上部門與學生互選功能。
- 人員管理：可以對已經加入部門的成員進行管理（删除、标星功能）。
- 發帖（模型中未展示）：在首頁上發帖，更全面的展示自己的部門。
- 評論回複（模型中未展示）：可以浏覽學生們在首頁的文章上的評論，并進行回複。
結隊項目——第一次作業 - 我加入的社團（此模型為院·文化部為例），可實作功能如下：
- 浏覽部門首頁文章并可以評論。
結隊項目——第一次作業 - 我管理的社團（此模型為院·實踐外聯部（副部長）為例），可以實作功能如下：
部門：
此部分可以展示所有的部門與社團（校學生會、社聯、院學生會（使用者的學院）、社團），可以通過搜尋功能查找想要了解的部門，每一個部門通過首頁的形式呈現，每一個首頁有很多文章，使用者可以進行評論功能，具體同“我的部門”中“文化部”形式相同。可以一鍵申請加入。
在模型中隻展示了院學生會中的文化部與實踐外聯部，其餘在實作上類似。
日程安排：
以月曆的形式展現日程，清晰明了。紅色代表當天，白色代表無安排，綠色代表有安排，月曆隻會顯示使用者已經加入的部門的日程。
個人設定：
個人設定分為以下幾個部分：
1. 修改頭像，因為存在文章這樣互動的功能，是以使用者喜愛的頭像也是必不可少的，點選頭像位置即可設定頭像。
2. 個人中心。個人中心可以實作以下功能：
- 修改頭像功能，同上。
- 修改非固定資訊（固定資訊：姓名，性别，學院，專業，年級，年制）。
- 登出。
- 空間清理。互動式網站浏覽文章不免會産生緩存檔案，是以特設空間清理功能。
- 關于我們。描述了一些作者資訊。
- 意見回報。使用者可以通過這個部分提出一些建議，友善app的改進。
結隊項目——第一次作業
以下為app模型展示：
點我檢視模型展示
開發工具
墨刀。建議新手使用，簡單易懂。
PSP表格
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 570 | 750 |
| · Estimate | · 估計這個任務需要多少時間 | 9.5*60 | 12.5*60 |
| Development | 開發 | 440 | 600 |
| · Analysis | · 需求分析 (包括學習新技術) | 2*60 | 2.5*60 |
| · Design Spec | · 生成設計文檔 | 1*60 | |
| · Design Review | · 設計複審 (和同僚稽核設計文檔) | 20 | |
| · Coding Standard | · 代碼規範 (為目前的開發制定合适的規範) | ||
| · Design | · 具體設計 | 3*60 | 5*60 |
| · Coding | · 具體編碼 | ||
| · Code Review | · 代碼複審 | ||
| · Test | · 測試（自我測試，修改代碼，送出修改） | 70 | |
| Reporting | 報告 | 130 | 150 |
| · Test Report | · 測試報告 | 1.5*60 | 100 |
| · Size Measurement | · 計算工作量 | 10 | |
| · Postmortem & Process Improvement Plan | · 事後總結, 并提出過程改進計劃 | 30 | |
| 合計 |
結對過程
分為四個階段
- 一起讨論。讨論出需求分析，并且有了最初的想法與模型。
- 一起開發。墨刀有團隊作業的功能，于是我們通過語音聊天，在各自宿舍，共同完成了app模型的設計。
- 模型修改。初步模型建立完成之後，還做了很多的添加和修改，完善了模型。
- 一起寫部落格。需求分析、psp表格為周琪文編寫，其餘内容為張旗編寫。
心得體會
張旗
哎呀，做界面真有意思，我就喜歡做這些！可以把很多的設計想法放進app中，就像photoshop一樣有意思！
周琪文
本次作業并不是第一次和别人組隊合作，但是依然有很多收獲。在原型的設計中，兩個人有沖突和讨論，但在總體上，兩個人還是互相幫助的居多。組隊合作最大的好處就是多一種思想和看問題的角度，比起一個人，這樣的過程對一個軟體的完善更有益處。在沖突時找到異同點，積極溝通，并對優劣進行取舍，相信在以後的實際工作之中也會發揮至關重要的作用。