[Beta階段]展現博客

1、團隊成員簡介與我的博客地址

團隊博客地址：http://www.cnblogs.com/wowotoubuaa/

江昊，項目經理
http://www.cnblogs.com/haoj/ 

王開，後端開發
http://www.cnblogs.com/wk1216123/ 

王春陽，後端開發
http://www.cnblogs.com/wcysoftware/ 

楊墨犁，前端開發（UI）
http://www.cnblogs.com/pikali/ 

徐丞，後端開發
http://www.cnblogs.com/ericxuc/ 

付帥，前端開發
http://www.cnblogs.com/fusluv/ 

王若愚，前端開發
http://www.cnblogs.com/ruoyuwang/ 

 

   

2、軟件工程展現

一） 團隊項目目標：
實現一個爲北航社團提供社團管理服務，爲學生提供社團服務的網站

      預期的典型用戶：
1.社團管理者小A：經過"北航Clubs"社團後臺，建立與發佈活動資訊，在收集活動報名同窗信息後，進行羣發Email及短信操做；管理社員名單；查看活動回覆。
2.學生小C：經過"北航Clubs"網站，參加社團或者瀏覽近期社團活動並報名，報名後收到社團管理者小A發來的活動信息；對活動進行評論，查看站內信。

       預期場景描述：

場景一	烤漆終於結束了，如釋重負的小江想報名參加凌峯社週末的外出活動，但該活動外場報名已經結束，負責人的聯繫方式也不得而知。就在這時，小江經過朋友的介紹，打開BuaaClubs網站，通過實名註冊後，進入到了活動首頁。小江迅速找到了凌峯社的外出活動，點擊該活動右下角的"我要報名"按鈕，彈出提示"報名成功"，並在隨後受到了凌峯社發送的與該活動相關的短信和email通知。終於，週末又能夠出去浪了！
場景二	凌峯社的負責人昊昊，因爲凌峯社做爲北航最大也最爲著名的社團之一，常常舉辦許多活動，可是因爲宣傳渠道有限，及時動用了大量的人力物力去作宣傳，依舊效果不是很理想。後來，昊昊得知北航社團平臺的發佈後，他主動聯繫網站的負責人，爲凌峯社創建了後臺帳號。他登錄進去後，跳轉到活動編輯頁面，編輯頁面簡單且易上手，他很快就變寫好了一個新的活動事宜，點擊"我要發佈"，這篇活動信息，就出如今了網站展現頁面的首頁了。
場景三	做爲大一新生的小芳，想要使本身的大學新生活更加豐富多彩，考慮加入幾個社團體驗一下。但她在百團大戰中並無找到本身心儀的社團。因而，她打開了北航社團平臺的網站，進入"社團薈萃"的頁面，數十個社團按照不一樣的分類排列展現出來，小芳興奮的查看着這些社團發佈的一些訊息，很快凌峯社就吸引了她的注意，她迫切的按下了"加入"的按鈕，申請加入凌峯社。後來的幾天，她收到了凌峯社的面試短信，最終如願進入了凌峯社的你們庭中。

   

預期用戶（實名制）數量：

初期達到50

   

 

二） 實際數據

訪問量：截至今日 6000+，訪客數 658

用戶： 已達到初步要求的50個

社團：3個

 

    

三）團隊合做

分工協做：    

前端驅動開發，API處於交互核心位置。

先後端經過後端制定的API文檔進行統一交互；先後端內部則繼續細分任務，其中前端的動態展現以及後端的Model層實現均採起告終對編程的方式，來保證項目的完成效率與正確性。 

 

成員分工及貢獻比

Member	角色	分工	具體量化	貢獻分數
江昊	PM&DEV	完成學生界面前端重構，實現較好的用戶體驗輔助測試若干API	4000行html 、css代碼	53
楊墨犁	DEV	社團界面的靜態實現，通知，歷史消息，評論，社員管理		47
付帥	DEV	增長新的社團後臺功能，包括社員名單管理、社員申請加入社團審覈、發送站內信、導出EXCEL社員名單、查看歷史站內信	1900行代碼（js、界面）	51
王若愚	DEV	增長新的社團後臺功能，包括社員名單管理、社員申請加入社團審覈、發送站內信、導出EXCEL社員名單、查看歷史站內信	1500行代碼（js、界面）	48
王開	DEV&TEST	二輪API設計文檔，二輪數據庫設計文檔 評論部分，登錄，身份驗證，實名驗證部分API	700行rails代碼 API文檔、數據庫設計文檔	52
王春陽	DEV&TEST	實現或修改了通知、站內信、文章以及評論等部分的API，負責Scrum meeting的發佈和管理，修改完善二輪API文檔	700行rails代碼 Scrum meeting文檔	50
徐丞	DEV&TEST	實現社團管理部分的API，負責一部分Scrum meeting的發佈和管理，測試編寫的API	400行rails代碼 Scrum meeting文檔	49

   

Github管理統計

  後端

 

前端

 

 

 

 

經驗教訓：

經驗之談

1.軟件架構設計提升開發效率

在進行開發前，咱們制定了API文檔，規定了API各項參數與細節，使得前端後端能夠徹底獨立開發，互相不受干擾與影響，專一於本身的技術領域，學習成本下降，開發效率提高。

2.任務的細化可讓每一個隊員都貢獻力量

經過API文檔，將項目任務細化爲前端與後端。

後端採用rails框架，自帶MVC結構，後端三人分別去作Model層、Controller以及Router

前端採用界面與JS代碼分離開發的方式，將任務分爲UI設計與界面實現、界面動態化展現。

因而任務以比較平均的方式細化到每一個人身上，爲每一個人設計了本身的關注焦點，調動起團隊的力量。

3.每週例會，不是形式

每週的例會推進項目不斷進展。每次到週會前，項目都會"進展神速"，實現本週要求的任務。

每週例會主要議題有兩個，第一個是該周目標與任務安排，第二個是介紹採用的新的技術方案or開發工具、開發方式。第一個議題，使每一個隊員明確本身的任務，任務明確，是一個開發人員進行開發的最大動力。第二個議題，使隊員知道接下來將如何和隊友合做，如何什麼樣的技術實現將要開發的功能。

好比，咱們在討論用戶狀態控制時，涉及到後端的Token存儲、API調用、前端sessionStorage存儲以及header傳遞身份信息的驗證方式，將整個技術流程介紹完畢，先後端隊員就理解如何更好的和對方配合了。

   

教訓之談：

API文檔要保證最新且真實可用

做爲最重要的團隊文檔，API文檔應該被精心維護，有動態更新應及時告知隊友。

團隊開發中，比較浪費效率的一次就是後端更改了API的一個參數，沒有及時更新API文檔，致使前端開發隊員苦調半天而無果。

   

 

五） 團隊如何平衡 時間/質量/資源 爭取如期完成任務的     

團隊總體：PM發揮PM的做用，面對天天的時間，找到優先級，做出判斷與分工。團隊經過天天的scrum meeting進行總結，對項目安排進行相應調整

先後端開發各自內部：經過我的能力與時間等依據，天天制定計劃分工與目標任務。

   

六） 代碼工程質量及數據證實

團隊代碼的軟件工程質量：

1. 最終代碼地址：https://github.com/buaaclubs-team

關於測試：

 在Beta階段，咱們主要進行了以下幾種測試：

• 單元測試
• 黑盒測試
• 兼容性測試
• 壓力測試

 

單元測試主要經過rails自帶的單元測試框架以及測試人員利用fiddler對請求返回的response進行檢查兩種方式進行。

Rails自帶的單元測試框架，經過編寫測試用例，而後執行測試用例並經過。因爲Beta階段實現的API有一些比較複雜，如發送短信，短信等功能。因此，簡單的API是經過rails自帶的單元測試框架測試的，其他大部分API都是經過fiddler4手動測試。

Fiddler4對API進行測試，測試流程是測試人員在Fiddler4中構造API請求，以後對得到的response body體中的各個參數進行檢查，並對測試結果截圖記錄。如下是測試記錄的相關截圖：

測試用例1：

Request：

Response：

測試用例2：

Request：

Response：

 

 

黑盒測試，主要發現瞭如下bug：

1. 社團成員信息沒法自動更新
2. 活動成員名單沒有對齊
3. 歷史消息頁面中，按鈕排版存在問題
4. 用戶界面中站內信未讀問題

 

兼容性測試，主要針對用戶和社團的各個頁面進行了瀏覽器的兼容性測試，測試的瀏覽器包括：火狐瀏覽器，IE瀏覽器，谷歌瀏覽器，搜狗瀏覽器

具體可見測試報告 http://www.cnblogs.com/wowotoubuaa/p/5117708.html

 

壓力測試，因爲Alpha階段沒有進行對軟件的壓力測試，因此在Beta階段咱們着重測試了這一方面。壓力測試的流程，經過編寫的python 腳本程序，同時發送上百條請求，記錄請求相應的時間，請求平均響應時間等相關參數。測試對象爲功能上比較重要的API。測試的結果顯示，對於不一樣API的500條請求，基本均可以在10s內響應完成，服務器未出現異常狀況

具體 http://www.cnblogs.com/wowotoubuaa/p/5117708.html

   

代碼規範：

因爲rails自己對代碼的規範有許多默認的約定，好比變量，常量的命名，路由，控制器，模型的命名等都有一套默認的規範，咱們在進行後端的編寫時聽從了rails自己默認的這些約定。而且，對api格式的規範還有註釋的要求進行了統一規定。

   

關於文檔：

保存於 https://github.com/buaaclubs-team/share-and-notify

 

   

3、   團隊項目的進展過程

燃盡圖進展趨勢

   

  總結：

scrum在大體上反映了咱們的項目進度趨勢：前期進展平穩順利，後期由於其餘學科的衝擊進度放緩；因爲迭代日期的緣由，TFS任務的更新也出現了一些問題。

   

   

4、  團隊從用戶那裏獲得了什麼反饋，有什麼樣的bug？這是預料之中的仍是沒想到的？

1.

這是一個BUG，屬於服務器和前端控制的侷限，是預料之中的

2.

預料之中，社團後臺界面的一些用戶體驗的侷限

3.

社團界面與用戶界面是分離的，屬於設計上缺陷

 

 

5、 相對於M1的改進

M2過後總結：http://www.cnblogs.com/wowotoubuaa/p/5118509.html

 

 

6、 總結，整個團隊在Alpha階段學到了什麼，對軟件工程的教育，對這個具體的課程有什麼批評建議？

總結：

1. 先後端技術
2. 團隊協做、溝通交流
3. 軟工開發模式的理解

批評建議：時間安排不穩當，致使時間資源不充足