我們是軟工頂級理解團隊，經過長達乙個月的alpha階段緊張刺激的開發，我們希望能夠提交無人轉會申請，其理由如下：
下面我們將詳細闡述我們的申請條件。
人員崗位
職責喬璽華、單彥博、張藝璇
前端進行android軟體介面開發
胡彬彬、李嘉鋮
後端進行伺服器互動邏輯**編寫
杜博瑋爬蟲
負責從教務獲取學生資料存到資料庫
郭駿pm
監督工作、寫部落格
姓名量化貢獻
喬璽華**行數2220，pull request 21個，bug 2個，額外開發issue 4個
張藝璇**行數1780，pull request 13個，bug 2個，額外開發issue 2個
單彥博**行數4011（包含框架打底**），pull request 21個，bug1個，額外開發issue 2個
李嘉鋮**行數1502，pull request 42個，bug 3個，額外開發issue 2個
胡彬彬**行數1582，pull request 32個，bug 2個，額外開發issue 4個
杜博瑋**行數433，commit 49個，bug 9個，額外開發issue 5個
郭駿我們團隊成員分工合理，開發積極，同組成員之間分工明確，任務均勻。
我們的開發模式是3人前端，2人後端，1人爬蟲，1人pm，這樣的合作方式非常適合我們團隊，是綜合能力、時間、長處、性格各方面因素的乙個平衡點，組內相處十分融洽。團隊成員中任何乙個人的離開，都可能會將這個平衡打破，新人的加入會增加許多磨合時間，對於我們這樣乙個開發任務較為繁雜的專案來說，影響較大。
時間註冊人數
課表訪問次數
成績訪問次數
ddl訪問次數
空教室訪問次數
登入次數
4/29 16:00
612300
445241
60174
4/29 20:00
1333989
788429
81316
4/30 18:00
1575243
941588
85399
5/1 18:00
2136710
1164
71698
5055/2 18:00
2237252
1233
81098
5205/3 18:00
2267432
1250
848110
5255/4 18:00
2227678
1265
896112
527我們的專案在發布後短短一周時間內，就達到了200人註冊的使用量，成功達到了課程組的要求。而這一數量作為乙個沒有官方推廣渠道，僅靠群內口口相傳的軟體來說，是非常難得的。
使用者使用反饋方面，雖然我們alpha階段的功能不算很多，但是每個功能的完成度較高，沒有什麼bug，ui較為整潔，所以使用者體驗良好，收到的反饋較為正向。
**質量：我們的專案有完善的介面文件，程式中有詳細的注釋，團隊部落格也非常完善。
審核質量：我們的專案通過github的issue和pr來串聯起整個專案，對每一行**都有code review來進行審核，在開發階段就對**質量有了把控，充分利用github的功能。
我們在beta階段，會優先解決以下問題：
如果我們有人員變動，專案想要如期完成需要我們付出更多的代價，也可能會讓新加入的人感受到壓力和不愉快。並且，我們專案質量較高，組內成員並不想跳槽出這樣乙個工作環境良好、軟體前景可觀的團隊。
以上就是軟工頂級理解團隊的無人轉會申請。我們會不斷努力，在beta階段為大家帶來更優質的產品。希望課程組能夠根據實際情況進行考量，批准我們的請求。
軟工頂級理解組 Beta階段事後分析
目錄和上乙個階段相比，團隊軟體工程的質量提高了麼？在什麼地方有提高，具體提高了多少，如何衡量的？使用者量，使用者對重要功能的接受程度和我們事先的預想一致麼？我們離目標更近了麼？有什麼經驗教訓？如果歷史重來一遍，我們會做什麼改進？團隊在計畫階段是如何解決同事們對於計畫的不同意見的？你原計畫的工作是否最...
軟工頂級理解組 Beta階段測試報告
在測試過程中發現了多少bug？你是怎麼進行場景測試 scenario testing 的？包括你預期不同的使用者會怎樣使用你的軟體？他們有什麼需求和目標？你的軟體提供的功能怎麼組合起來滿足他們的需要？在alpha階段已經提到的使用者型別，此處不再提及。此處提及預期使用者會如何使用我們的新功能。經常忘...
軟工頂級理解組 0526第31次會議
人員 昨日完成任務 明日要完成的任務 孫旭東美化頁面 繼續美化頁面，改介面為測試服版本 張藝璇寫評價頁面與後端對資料格式，技術部落格 修改校歷頁面的bug 單彥博完成課程評價詳情頁面 測試課程評價相關功能 胡彬彬暫無任務 暫無任務 李嘉鋮與前端對接資料格式 暫無任務 杜博瑋完成技術部落格和wiki ...