一、需求分析：
1.用戶訪問：
我們本身做的就是具有在線問卷調查功能的軟件，所以我們就沒有采用問卷調查的方式來進行用戶調研。但是從其他團隊所作的項目中可以看出，他們大多數還是用問卷調查這種方式來進行用戶調研，所以這種方式對於大學生來說，還是受歡迎的。而且在朋友圈里，也經常可以看到問卷調查這種方式。
2.需求規格說明書的git鏈接
This is an example link
3.項目的NABCD
need需求：面向學生群體的問卷平台是當前市面上所缺少的存在，大多數校園針對性在線問卷工作都是由教育機構網站兼職操作，要么參與度低、要么任務式流程缺少了答案的真實性，這正是說明市場需要一個專用的平台接入廣大的學生群體，提供一個自由、開放的問卷平台
approach做法：提供兩套用戶賬戶功能，發布者賬戶可在本平台上進行自定義的調查內容設定、編寫，並設定參與者的相關信息條件限制（如規定可參與者的年齡、性別等），達到精准投放的效果並通過本平台進行發布。被調查賬戶可在本平台上填寫必要的個人信息后自由選擇發布者發布的問卷進 行填寫並提交。而后發布者賬戶可查看上交的問卷數據統計。
benefit好處：針對校園群體的調查網站，可以讓學生、教師等（受調查問卷者）與發布者進行直接而高針對性的信息交流，學生只需擁有一個賬號，即可任意參與符合自身條件的調查問卷，發布者也能得到有效而准確的信息
competitors競爭：目前市面上已經存在了不少的調查問卷網平台，但是依然在正常維護運營的平台已經為數不多，如第一調查、集思網等，而多數是處於停滯狀態，效率低下
delivery 交付：上線后可在校園論壇和校園APP等場所進行宣傳推廣，且可以建議問卷發布者通過對用戶參與問卷調研環節之后提供相應的獎勵措施，促進平台的推廣和運營，甚至在條件允許的情況下直接接入校園APP。
4.項目的殺手功能：
專門針對學生群體，擁有最准確的用戶指向性，確保問卷調查投放的目標精准、高效。
5.將NABCD要點組織成一段話：
我們的平台以一個完整的問卷調查體系為目標，建立一個問卷調查平台，被調查對象限定在學生群體，發布調查問卷權限向社會各個機構、組織、個人開放。系統主體功能包含完整的發布和填寫、后期的數據查詢統計。力圖做到快、准、簡三個原則。
二、原型設計：
1.原型設計的結果和原型設計用到的工具，需要圖文並茂
用戶主界面：
管理員界面：
用戶界面
用戶注冊界面
三、任務分解：
1.團隊項目的WBS
2.成員估計各自任務所需時間
| 功能 | 人員 | 時間 |
|---|---|---|
| GUI界面 | 張金偉 羅駿 | 15h |
| 問卷自定義框架 | 馮鳴 | 20h |
| 用戶群組系統、賬戶系統 | 詹昌錦 盧傑 | 20h |
| 提交、遷入數據庫 | 葉金蕾 盧傑 | 25h |
| 查詢后台信息 | 羅駿 詹昌錦 | 20h |
| 最高權限 網站后台管理 | 張金偉 葉金蕾 | 20h |
三、編碼規范：
1.制定團隊的編碼規范，給出Git鏈接
普通變量：
普通變量命名遵循以下規則：
a． 所有字母都使用小寫；
b． 對於一個變量使用多個單詞的，使用’_'作為每個詞的間隔。
例如：$base_dir、$red_rose_price等
靜態變量：
靜態變量命名遵循以下規則：
a． 靜態變量使用小寫的s_開頭；
b． 靜態變量所有字母都使用小寫；
c． 多個單詞組成的變量名使用’_'作為每個詞的間隔。
例子：$s_base_dir、$s_red_rose_prise等。
局部變量：
局部變量命名遵循以下規則：
a． 所有字母使用小寫；
b． 變量使用’_'開頭；
c． 多個單詞組成的局部變量名使用’_'作為每個詞間的間隔。
例子：$_base_dir、$_red_rose_price等。
全局變量：
全局變量應該帶前綴’g',知道一個變量的作用域是非常重要的。
例如
global $gLOG_LEVEL;
global $gLOG_PATH;
全局常量：
全局變量命名遵循以下規則：
a． 所有字母使用大寫
b． 全局變量多個單詞間使用’_'作為間隔。
例子：$BASE_DIR、$RED_ROSE_PRICE等。
類：
類命名遵循以下規則：
a． 以大寫字母開頭；
b． 多個單詞組成的變量名，單詞之間不用間隔，各個單詞首字母大寫。
例子：class MyClass 或class DbOracle等。
方法或函數：
方法或函數命名遵循以下規則：
a． 首字母小寫；
b． 多個單詞間不使用間隔，除第一個單詞外，其他單詞首字母大寫。
例子：function myFunction ()或function myDbOracle ()等。
縮寫詞：
當變量名或者其他命名中遇到縮寫詞時，參照具體的命名規則，而不采用縮寫詞原來的全部大寫的方式。
例子：function myPear（不是myPEAR） functio getHtmlSource（不是getHTMLSource）。
數據庫表名：
數據庫表名命名遵循以下規范：
a． 表名均使用小寫字母；
b． 對於普通數據表，使用_t結尾；
c． 對於視圖，使用_v結尾；
d． 對於多個單詞組成的表名，使用_間隔；
例子：user_info_t和book_store_v等
數據庫字段：
數據庫字段命名遵循以下規范：
a． 全部使用小寫；
b． 多個單詞間使用_間隔。
例子：user_name、rose_price等。
書寫規則：
代碼縮進：
使用4個空格作為縮進，而不使用tab縮進
大括號{ }書寫規則：
在程序中進行結構控制代碼編寫，如if、for、while、switch等結構，大括號傳統的有兩種書寫習慣，分別如下：
a．{直接跟在控制語句之后，不換行，如
for ($i=0;$i<$count;$i++) {
echo "test";
}
b．{在控制語句下一行，如
for($i=0;$i<$count;$i++)
{
echo "test";
}
小括號( )和函數、關鍵詞等：
a． 不要把小括號和關鍵詞緊貼在一起，要用一個空格間隔；如if ( $a<$b )；
b． 小括號和函數名間沒有空格；如$test = date("ymdhis")；
c． 除非必要，不要在Return返回語句中使用小括號。 如Return $a；
符號書寫：
a． 在=符號的兩側，均需留出一個空格；如$a = $b 、if ($a = = $b)等；
b． 在一個申明塊，或者實現同樣功能的一個塊中，要求=號盡量上下對其，左邊可以為了保持對齊使用多個空格，而右邊要求空一個空格；如下例：
$testa = $aaa;
$testaa = $bbb;
$testaaa = $ccc;
對於控制結構的書寫遵循以下規則：
a． 在if條件判斷中，如果用到常量判斷條件，將常量放在等號或不等號的左邊，例如：
if ( 6 == $errorNum )，因為如果你在等式中漏了一個等號，語法檢查器會為你報錯，可以很快找到錯誤位置，這樣的寫法要多注意；
b． switch結構中必須要有default塊；
c． 在for和wiile的循環使用中，要警惕continue、break的使用，避免產生類似goto的問題；
如果要在類里面編寫構造函數，必須遵循以下規則：
a． 不能在構造函數中有太多實際操作，頂多用來初始化一些值和變量；
b． 不能在構造函數中因為使用操作而返回false或者錯誤，因為在聲明和實例化一個對象的時候，是不能返回錯誤的；
語句斷行, 每行控制在80個字符以內
在代碼書寫中，遵循以下原則：
a． 盡量保證程序語句一行就是一句，而不要讓一行語句太長產生折行；
b． 盡量不要使一行的代碼太長，一般控制在80個字符以內；
c． 如果一行代碼太長，請使用類似 .= 的方式斷行書寫；
d． 對於執行數據庫的sql語句操作，盡量不要在函數內寫sql語句，而先用變量定義sql語句，然后在執行操作的函數中調用定義的變量；
例子：
$sql = "SELECT username,password,address,age,postcode FROM test_t ";
$sql .= " WHERE username='aaa'";
$res = mysql_query($sql);
四、系統設計：
1.系統的架構設計
2.團隊項目的數據庫設計，並在隨筆中提供相應ER圖
【成員的完成情況】
【個人的感受】
張金偉：周末小組開了討論，會上決定該如何實施這個項目，並且也詢問了老師，應該如何做好，老師給的建議是從從基礎學習，先實現頁面的交互，我也在課余時間學習了HTML和CSS的前端視頻。發現該項目所需要的技術還是挺多的，自己並不是很了解，打算這周先把前端學好，實現界面的交互。
馮鳴：剛開始做這個團隊編程時，自己還是一頭霧水，不過在小組的討論下，內心逐漸有了方向和目標，也大概知道了自己應該做什么內容，接下來的環節，也要好好去做，把自己的每一步都做到最好。接下來的每一步都是十分重要的，要盡力跟隨團隊的腳步，把這個項目做好。
詹昌錦：本周進行了小組討論，更加明確了各自的任務，包括項目整體的結構以及整個項目具體的功能，界面設計。目前只有大概的一個雛形，然后我們每個人各自去學習所屬任務區域的技術，雖然說現在對技術這些還不是很熟練，但相信經過后面幾周的訓練，會更加如魚得水的，我相信我們會做好這個項目的。
羅駿：本周結束之后，我們的團隊整個前期准備、規划工作，對后期任務計划已經算是完全完成，接下來就是投入到最重要最有挑戰性的實際開發環節中去了，很顯然，在此之前我們團隊似乎還是一團亂麻一般找不到方向，經過這周團隊作業詳細的需求分析設計之后，一切都仿佛箭在弦上，接下來的實際操作環節，就是體現我們本周團隊計划任務是否有效、合理的階段。從需求分析到系統設計，我已經感覺到接下來的開發環節比預想的要更加復雜和具有挑戰性，總之要盡力配合，協力完成
葉金蕾：在上周的談論后，我們這周對整個項目的框架運用，服務器等語言選擇及編碼規范做了一個說明。包括前端界面的樣式，具體的功能。我相信通過我們的目錄，我們會完成好這個項目。
盧傑：在上周的分工基礎上，我們這周對整個項目的流程進行了討論，包括前端界面如何進行構建，后段語言的選用和處理，相應數據庫的連接和規划。雖然現在可能依舊一頭霧水，但我們依然在路上，我們從基礎知識開始，去學習那些知識，以期待着在接下來的幾周內可以一步一個腳印得向上攀爬。