2021北航敏捷軟工Beta階段評分與總結

概述

Beta 階段評分，按照之前的規則，主要組成部分爲：

• 博客部分，基於 Beta 階段博客的評分（每篇正規博客 10 分，每篇 Scrum5 分，評定方式類比往年）
• 評審部分，基於 Beta 階段展示、答辯以及現場工作的評分（150 分）
  • 現場評分。基於現場點評給出的排名進行打分，以此分項評級並打分，全員以及大衆評審團（除參與複審的人員之外，即韓滏婧、劉紫涵、劉取齊、趙博名、胡緒佩五位助教、各個小組以及大衆評審團成員）都將參與，總計 50 分（評審整體規則見：Beta階段現場評審規則及表格，表格見：Beta現場評審表格）
  • 複審評分。基於客觀上限定的給分點進行專業性更高的打分，僅由部分主要助教和老師（暫定：羅傑老師、任建老師、劉乾、張少昂、劉陽、周雨飛）共同參與，總計 100 分（目前的參考評分標準：Beta階段複審規則及表格，評審表見：Beta階段複審表格）

上述評分組成的具體詳情見後文。

評分

博客評分

博客部分評分整體上參考2020年Beta階段評分規則，其中

• 功能規格說明書、技術規格說明書、發佈說明、測試報告、事後分析，滿分爲 10 分，各團隊之間作業質量進行對比，最高得 10 分，最低得 0 分。
• 每日例會博客的評分規則爲：
  • 滿分爲 5 分；
  • 報告每個人的工作、燃盡圖、每日例會的照片三個部分，並且內容屬實的，得滿分；
  • 少任何一個，或者某一項內容不真實，扣除 2 分，以此類推，扣完爲止；
  • 若某一項內容不完整，酌情扣 1 分；
  • 對於格式混亂的情況，酌情扣 1 分；
  • 遲交兩週以內，得 0 分；
  • 遲交兩週或更多，倒扣全部分。

團隊名稱	功能規格說明書（10）	技術規格說明書（10）	發佈說明（10）	測試報告（10）	事後分析（10）	每日例會博客（一次5分）							合計	排名
						1	2	3	4	5	6	7
謎語人隊	10	9	10	7	9	4	3	5	4	5	5	5	76	7
髮際線和我作隊	10	9	10	8	9	5	5	5	5	5	5	4	80	3
美滋滋甜兮兮隊	10	10	10	10	10	4	5	5	5	5	5	5	84	1
萬里陽光號	8	7	9	10	8	5	5	5	5	5	5	5	77	5
是兄弟就來摸魚	9	9	10	10	8	3	5	4	5	4	5	4	76	7
助教團隊	10	9	10	10	9	5	4	4	4	5	5	4	79	4
刪庫跑路對不隊	10	9	10	10	10	5	5	5	5	5	5	5	84	1
蕩起雙槳	9	10	8	7	9	5	5	5	5	5	5	4	77	5

現場評分

評審規則

本次現場評審部分基本規則如下所示：

	評分說明	評分方式與要求
現場展示質量	到場情況——團隊成員是否有無故缺席的情況？ 展示效果——現場講解、回答問題的水平如何？ 互動意願——現場互動的積極性和質量如何？	採用評級方式，依據如下 A——優秀，無無故缺席情況，現場展示效果優秀，且互動積極 B——良好，無無故缺席情況，現場展示效果良好，有一定的互動 C——一般，存在人員無故缺席，或展示效果欠佳，完全無講解以外的互動 D——較差，存在較多人員無故缺席，或展示內容令人難以理解 理由要求 對於 C、D 檔，必須明確說明理由，不少於 20 字
軟件質量	需求指標——需求指標是否合理？ 數據真實性——所展示的用戶量、日活等數據是否真實？有多大的水分？ 軟件效果——軟件是否可以較好且便捷的解決用戶的需要？ 指標完成度——預定的需求指標完成程度如何？	採用評級方式，可參考以下標準 S——卓越，需求指標合理且有挑戰性，軟件效果極好，且大幅度超額完成需求指標（原則上不少於300%）或做出了長遠貢獻（成功的開源、被認定爲官方應用、得到融資等） A——優秀，需求指標合理且有挑戰性，軟件效果優秀，可以較好解決用戶需求，圓滿完成了需求指標（原則上不少於95%） B——良好，需求指標合理，軟件效果良好，可以解決用戶的需求，基本完成了需求指標（原則上不少於80%） C——一般，需求指標較低，軟件效果一般，可以解決用戶部分需求，面向了用戶且勉強完成了部分需求指標（原則上不少於50%） D——較差，需求指標很低，軟件效果較差，難以解決用戶大部分需求，完成的需求指標量很低或未面向用戶。 評級要求 S 共計不超過 1 個 S、A 總計不超過 3 個 同一評級不超過 3 個 理由要求 無論任何評級都必須詳細說明理由，不少於 40 字
軟工質量	軟件性能——軟件經過測試和實際運行，能達到什麼樣的高性能水平？ 軟件可靠性——系統可以保證多大程度上的持續運行？團隊是否有壓測？是否有收集錯誤反饋的相關機制？ 軟件安全性——軟件有多少維持系統本身安全的能力？有多少保護用戶數據安全的能力？ 工程可擴展性——代碼架構如何？是否配備了單元測試？整體代碼質量如何？是否有長期持續維護這一質量的手段（如CI中運行單元測試）？ 工程可維護性——代碼風格如何？註釋完整性如何？文檔是否完善？整體工程質量如何？是否有長期持續維護這一質量的手段（如CI中運行代碼風格檢查）？是否配有自動構建/打包/發佈/部署等環節？	採用評級方式，可參考以下標準 S——卓越，軟件性能極高，可靠性經測有很大的餘量，安全性高，可擴展性極高且配備完整的持續化手段，可維護性極高且配備完整的持續化手段 A——優秀，軟件性能優秀，可靠性完全滿足要求，安全性高，可擴展性較好且有一些持續化手段，可維護性較好且有一些持續化手段 B——良好，軟件性能滿足要求，可靠性沒有大問題，安全性較高，可擴展性滿足持續擴展的要求，可維護性滿足持續開發的要求 C——一般，軟件性能有少量問題，可靠性存在少量問題，有一定的安全風險，可擴展性較低，可維護性較低 D——較差，軟件性能難以滿足基本需求，可靠性較差，有高危的安全風險，可擴展性很低，可維護性很低 評級要求 S 共計不超過 1 個 S、A 總計不超過 3 個 同一評級不超過 3 個 理由要求 無論任何評級都必須詳細說明理由，不少於 40 字
綜合	基於上述三方面，給出一個整體的排名	採用排名方式 需要與各部分的評級相匹配，保證最基本的合理性

助教1

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	A		β階段日活躍用戶爲40人	A	前端設計精美、豐富，特別是引導頁面。 總體完成效果好，較好地滿足了目標需求。 針對文本和音頻的可視化特殊性太強。	A	Gitlab 使用情況好，milestone、issue 設置合理，說明詳細、燃盡圖真實、較好地完整完成了計劃任務。 代碼風格檢查、CI/CD 使用情況好。	2
髮際線和我作隊	A		發佈一週後，下載量 200-300，活躍用戶量 50-100	B	遊戲完成度較好、可玩性強，按計劃完成任務。遊戲存在出現概率較大的 bug。	B	討論過的 apk 過大的問題仍未解決。軟件可靠性一般。	5
美滋滋甜兮兮隊	A		一週後用戶量 300	S	對需求目標完成情況良好，對項目進一步推廣、拓展、立項。數據真實性強，給出的日活、用戶量等數據已自行去除水分，軟件整體質量效果好。	S	項目管理詳細、真實。幾乎針對每個 issue 都有具體內容的說明和關聯信息。也給出了許多值得學習的精彩範例。	1
萬里陽光號	B		註冊人數 200-300 人，活躍用戶數 100-200	C	軟件存在較爲明顯的小 bug，應當在早期測試中就發現。 軟件在一些小問題上的處理方法不夠簡潔、使用感受一般。	C	使用多種工具進行項目文檔管理。 測試方面展示出的工作內容不太充分。 gitlab 上的 issue 較少。	8
是兄弟就來摸魚	B		發佈一週內使用次數達到 300	C	順序練習時只要退出後再次進入時又會從第一道開始	C	代碼倉庫的使用情況不夠好。CI/CD 的使用情況一般。	6
助教團隊	A		一週日活 200，兩週日活 300	B	界面與 alpha 相比，更加人性化，而且支持移動端。 部分功能，如疫情相關機構的搜索功能，提示不明顯。 整合各種數據源。	A	團隊的分工計劃表格具體、詳細，團隊成員貢獻記錄詳細。 測試完善，完成了對多種設備的適配性測試，可靠性好。	3
刪庫跑路對不隊	A	製作了生動精美的展示宣傳視頻。	日活用戶爲 400	A	宣傳力度大、手段豐富	B	沒有做代碼風格檢查，代碼管理使用整體放入一個倉庫與各部分分別倉庫結合的方法，項目文檔詳細、規範。	4
蕩起雙槳	A		發佈一週網頁端用戶量 200-400	C	實際的應用效果一般，不太能識別出詢問的相關主題。	B	沒有做代碼風格測優，使用項目管理工具情況一般。	7

助教 2

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	A	展示效果較佳，互動積極，回答問題流暢有重點	β階段日活躍用戶爲40人	B	考慮了多種數據類型，進行了相應的可視化，較好解決了用戶的需求，但日活離預定指標還有一點差距，未給用戶在使用上給出更好的指導	A	分工較明確，issue 粒度劃分較細，採用 CI/CD 進行了較完整的單元測試和代碼規範檢查。	3
髮際線和我作隊	A	展示效果佳，製作了小視頻。互動較好。	發佈一週後，下載量 200-300，活躍用戶量 50-100	B	beta 階段增加了遊戲的隨機性和趣味性，實現了多人聯機功能。基本解決了輕量級、聯機等需求，日活達到預期指標，但軟件存在一些小 bug。	C	採用了 Plastic SCM+git 兩種工具進行管理。單元測試覆蓋率達 98%。數據庫 中存放的是明文密碼，安全性稍有欠缺。	6
美滋滋甜兮兮隊	A	製作了 demo 視頻，展示充分有重點。互動階段，對答如流。	一週後用戶量 300	B	軟件功能全面， 完整性較高。在 alpha 的基礎上進行了很多細節的優化。累計用戶達 253 人，與預定指標有一點差距，但在有效宣傳之後有望完成指標。	A	以 issue 和石墨文檔進行管理，對 issue 的具體進展情況進行實時追蹤，流程清晰。進行了單元測試和壓力測試。對前端採用了 CI/CD，但整體部署不完善，倉庫管理存在部分未整理的東西。	2
萬里陽光號	B	展示效果較好，有互動	註冊人數 200-300 人，活躍用戶數 100-200	C	基本完成預期功能，註冊人數完成了預期指標，但真實日活的數據尚存疑。軟件存在一些小 bug，交互有些不流暢。	C	摒棄了輪值 PM 的制度。基於飛書和 gitlab 進行項目管理，但 issue 粒度較大。對各位同學的工作進行組內互評。進行了單元測試和壓力測試，並部署了 CI。	8
是兄弟就來摸魚	A	展示效果較好，製作了視頻	發佈一週內使用次數達到 300	B	累計註冊用戶達到 408 人，達到預期；日活量平均 100 人左右。打卡和成就係統不錯。	B	項目管理流程清晰，並進行了文本規範。部署了 CI/CD，但並不完善。	5
助教團隊	A	展示效果較佳，互動積極	一週日活 200，兩週日活 300	A	目標用戶明確，基本解決了用戶的需求，出色地完成了日活等指標。相關的功能較全面，提供了一些人性化的優化，但新增的出行建議界面略顯簡陋。	C	利用 issue 進行項目管理，issue 劃分粒度合理，但任務完成的跟蹤情況並不好，很多 issue 下並沒有評論。CI/CD 並沒有實際上用上。	4
刪庫跑路對不隊	A	製作了視頻，視頻質量很高，並做了視頻總結。	日活用戶爲 400	A	日活達到 200，但預期指標可能較高，具有挑戰性。功能覆蓋全面，界面也非常優美，實時判題和統一判題功能優秀。	S	項目管理優秀，劃分爲題士，產品主頁和後臺管理三個項目分別管理。部署了 CI/CD，測試覆蓋率高	1
蕩起雙槳	B	展示較好，有一定的互動	發佈一週網頁端用戶量 200-400	C	產品累計瀏覽次數超過 300 次，活躍註冊用戶 30 人左右，與預期。項目難度可能較大，實現的功能並不完善，未能很好地解決用戶的需求。	B	項目擁有完整的文檔和清晰的存檔結構，擁有全面的開發文檔。項目部署了 CI/CD 進行自動化測試。	7

助教 3

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	A	沒有什麼太大問題，聽得清，項目展示到位，做了的的功能都展示出來了	β階段日活躍用戶爲40人	B	相比於上一階段有了非常大的改進，不過小問題還有一些，突然出現的英文標籤以及不會收回的懸浮框，可改進地方不少。	S	少昂都誇了那沒啥好說的了	3
髮際線和我作隊	A	這個視頻我很喜歡，有那感覺了，這次發言的同學相較於上次也更自信了，講的很不錯。	發佈一週後，下載量 200-300，活躍用戶量 50-100	A	加入了更多的棋子以及聯機對戰讓可玩兒性變高了很多，雖然用戶們反饋的一些問題例如屏幕還沒解決，但總體質量不錯，我也親自玩兒了一下，我比較喜歡的是他們的想法，這種結合爐石和自走棋，對運氣，運營，和對卡組的理解三者缺一不可，是一種不錯的玩兒法。	C	其實我本來想給 B，但我感覺這個明文密碼還是有點兒問題的，屬於比較大的安全性問題了，此外關於 git 的使用雅哲說的也有可以借鑑提高的地方。	4
美滋滋甜兮兮隊	A	遠航唯一的問題是語速有點兒快，其它都挺好。	一週後用戶量 300	S	該軟件在 alpha 階段後吸取了廣大用戶的意見進行了改進，雖然目前還存在 bug，但其功能完備，能滿足絕大多數用戶需求。上一次 alpha 階段我的質疑點在 A4 紙背單詞法是否真的有效，但經過詢問我外交學院的同學，他認爲該項目有意義，能提高背單詞效率。此外該軟件還成功申請了大創，有開創性的貢獻。因此我認爲該軟件非常優秀。	A	給 A 主要是我在實際使用時感覺複習時加載速度有點兒緩慢，同時還有一些 bug 存在，所以稍微扣一點兒分，此外代碼管理裏.idea 和不同分支沒 merge 也有點兒問題。	1
萬里陽光號	A	講的聽清楚的	註冊人數 200-300 人，活躍用戶數 100-200	C	折線圖顯示有問題，扇形圖標題和模板有重合，交互不流暢	B	gitlab 的測試 milestone 開了但是進度爲 0，gitlab 的 milestone 普遍開的 issue 較少	6
是兄弟就來摸魚	A	發言老哥聲音蠻好聽的，中氣很足，展示到位	發佈一週內使用次數達到 300	C	UI 相較於上一階段變好看了很多，但由於這個項目比較特殊，有直接的對比小組，因此在我看來這個組做的遠不及題士（功能，界面），工作量感覺也不是很大	C	文檔有點兒草，git 管理不太到位，基本把所有放到了一塊兒。	8
助教團隊	A	可能是錄播的問題，聲音很小，斷斷續續的，有點兒影響觀感。	一週日活 200，兩週日活 300	B	我在 alpha 階段認爲該項目的問題是工作量，很多要完成的任務我看都沒完成，而 beta 階段適配了移動端以及優化界面解決了一部分問題，但我感覺之前畫的大餅沒喫完，還有工作可以去完成	C	理由同上，CI/CD 甚至是基本 failed。	5
刪庫跑路對不隊	A	圖文並茂，qsy 語速也很適中，回答問題很清晰	日活用戶爲 400	A	我大概試了一下，首先主頁已經吸引了我，真的很不錯。相比於單詞組，其實這兩個軟件我認爲都很不錯，個人我更喜歡單詞組的創意，因此給題士第二名	A	我個人沒發現啥問題，感覺不錯	2
蕩起雙槳	A	其實可以在博客裏多做對比，而不是讓觀衆去回想你們 alpha 階段的界面，這樣不直觀，其他都不錯	發佈一週網頁端用戶量 200-400	C	我個人不是很懂 NLP，但我使用感覺是這個 AI 也並不是很智能（甚至我都認爲這不能算個合格的 AI 產品的驗收標準），如下圖	B	git 也沒有 merge，老問題	7

助教 4

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	A		β階段日活躍用戶爲40人	A	展示效果與實際體現相符合，對於現有的數據集可視化軟件做出了改進，其支持數據集管理的特點在未來有利於發展成爲社區模式，具有較大的前景和空間，但是美中不足的是既然已經調研到了其他軟件有 leaderboard 的功能，可以考慮提供對公開數據集榜單的支持。	A	完備的前後端開發以及文檔管理，每一條 MR 的分類和具體做的事清晰明瞭，無論是 unittest 還是 os 兼容性測試都非常完善，如果有在線的發佈就可以是 S 級別了	1
髮際線和我作隊	A		發佈一週後，下載量 200-300，活躍用戶量 50-100	C	首先承認其工作量，開發一款遊戲從建模到各個流程和步驟的編寫是十分困難的，但是就是因爲想要做好一款遊戲所需要花費的時間和人力巨大，在軟件工程這一門一個學期的課程上想要做到一款有可玩性的遊戲還是比較倉促，目前從展示視頻看來受限於玩法的單一，真正開始戰鬥之後用戶的參與度可能不足（個人主觀感受，本身對卡牌類遊戲不是很感冒），還有一定的開發空間。	D	CI/CD 中僅看到對後端少有的一點 unittest 以及缺少 linttest，unity 部分沒有任何測試。MR 和 Issue 的管理比較迷惑，對倉庫介紹的欠缺，倉庫中 .vscode 和 pycache 的存在，以及隱患無窮的明文密碼存儲。	8
美滋滋甜兮兮隊	A		一週後用戶量 300	A	社區的建立讓我對 A4 記單詞更加耳目一新，創新的分享和 fork 詞圖讓網頁端的 A4 記單詞有其存在的價值，對於一開始可能懷疑的爲什麼能比紙質記單詞好的一系列疑問不攻自破。 爲什麼沒有 S 級：選題的價值決定了評級的上限，背單詞的軟件就算做成現在這種可以進行大創立項的較爲完備的產品，還是缺少其作品的內在價值，大概是雪中送炭>錦上添花的意義	B	比較可惜的是沒有找到線上 CI/CD 的解決方案，本地的 CI/CD 不太具有說服力，不能做到每次 submit 都觸發的回顧測試和單元測試。文檔的整理和前後端都比較齊全。MR 的使用方式雖然不是不行，但是挺令人疑惑的。	2
萬里陽光號	A		註冊人數 200-300 人，活躍用戶數 100-200	B	首先從開始就沒有真正回答心中的疑惑，爲什麼要在手機上繪製圖表，這種繁瑣的需要手動選擇數據調節的事項，最後的成品來看雖然 beta 有較於 alpha 的改進，但是受限於手機的屏幕大小和操作性，圖表的展示也沒有特別吸引用戶的地方，也沒有非常的特色。	C	缺少 unittest 和 codelint 部分，倉庫缺少說明，對 .DS_Store 等文件沒有進行過濾，後端倉庫給人一種凌亂的感覺，裏面有各種類型的文件和表意不明的 commit 內容。前端完全沒有配置 CI/CD，不太清楚是如何進行單元測試和發佈的。	7
是兄弟就來摸魚	A		發佈一週內使用次數達到 300	B	Beta 階段的產出相較於 Alpha 階段有了明顯的改進，微信小程序的各項功能也非常齊全，比賽模式也具有特色，但是相較於其他組的選題上還是差了一點，核心的刷題功能確實很難做出創新。	C	unittest 和 linttest 全是失敗，但是 MR 和 issue 部分做的比較細緻，倉庫如果能將前後端和文檔分開會更好一些。	6
助教團隊	A		一週日活 200，兩週日活 300	A	非常有意義的工作，將疫情的動態通過各種展示方式呈現出來，但是時效性可能存疑，比如 6 月 20 日中國總計接種超 10 億次，網站依然是 9.6 億，對於一個健康相關的工具類的網站而言，時效性應該放在首位。	C	unittest 全是失敗，install 步驟中也有 cannot stat 的錯誤。MR 信息沒有含義，倉庫中存在 .vscode 等沒有過濾的無用信息。	4
刪庫跑路對不隊	A		日活用戶爲 400	B	整個軟件的完成度達到了要求，各種功能也非常完備，但是從選題的意義出發還是沒有達到 A 的水平，畢竟前有 Questionor 和航概斬，同期有自救題庫，後有 ios 航概，差異化在 ui，核心功能比較雷同。	A	非常完備的 unittest 測試，細緻的文檔管理和倉庫管理，前後端和文檔如果能拆分成爲不同的倉庫可能會更好。Issue 和 MR 部分做得非常細緻。	3
蕩起雙槳	A		發佈一週網頁端用戶量 200-400	C	目前的產品從使用的體驗來說感覺還可以真正稱作 AIBot，當然受限於較短的開發時間和 AI 問答自身的學習開發難度，想要做到可以流暢問答不太現實。對於特色的靜態代碼檢查功能感覺實現比較倉促，從有一些沒有翻譯的英文提示來說感覺就是一個套殼的其他網站的 API 調用，可以再細化一下包括翻譯警告和提示。	B	unittest 覆蓋率只有 50%，註冊郵箱缺少驗證，倉庫中前後端和文檔最好分開，MR 和 issue 部分無功無過。	5

助教 5

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B	展示比較枯燥但基本到位。互動回答問題也比較正常。	β階段日活躍用戶爲40人	B	日活數據完成度達 90%，軟件效果良好，基本功能完成指標比較合理。	A	軟件安全性滿足基本要求，沒有較爲出彩的說明該問題，軟件測試比較完善	3
髮際線和我作隊	B	演示情感飽滿，表述清晰。有 demo 視頻演示，直觀易懂。	發佈一週後，下載量 200-300，活躍用戶量 50-100	B	日活數據完成度較好，其他需求指標也完成較好。	B	軟件測試模化有提及，覆蓋率達 98%，比較突出。 傳輸雖然加密，但是數據庫中是明文存儲，安全性影響較大。	5
美滋滋甜兮兮隊	A	聲音洪亮，demo 視頻展示較爲直觀清晰，互動積極。	一週後用戶量 300	A	用戶量較高，同時指標計算合理，日活數據正常，並且訪問量及宣傳方面完成的非常優秀。	A	安全性較高，測試比較完善，全程 git 管理存在瑕疵。	2
萬里陽光號	B	展示動圖具體講解，聲音洪亮，但回答問題還需要提高。	註冊人數 200-300 人，活躍用戶數 100-200	B	用戶量較爲合理，功能部分存在部分缺陷，指標完成還算正常，但計算不夠完美嚴謹。	C	測試及安全性可靠性問題還存在一些，代碼風格存在缺陷，git 使用還有一些問題。	7
是兄弟就來摸魚	B	聲音洪亮，感情飽滿，動圖 demo 演示直觀清晰。	發佈一週內使用次數達到 300	B	宣傳手段不錯，各個用戶量指標完成的也非常不錯。	C	代碼倉庫管理不夠好，工程性有些欠缺，CI/CD 使用存在一些問題。	8
助教團隊	B	展示內容較爲全面，聲音洪亮，視頻播放存在一定問題。	一週日活 200，兩週日活 300	A	用戶指標完成較不錯，用戶留存率較高，很不錯。	C	CI/CD 使用及倉庫代碼屬於倉促完成，數據倉庫使用存在部分問題，git 使用不夠好。	6
刪庫跑路對不隊	A	展示視頻非常新穎有趣直觀，但內容還不夠完整充實。	日活用戶爲 400	S	日活 200+，雖然和預期有些差距，但是還是非常不錯，宣傳手段很豐富。	S	CI/CD 使用較好，並且代碼倉庫管理也很不錯。	1
蕩起雙槳	A	聲音洪亮，展示邏輯較好	發佈一週網頁端用戶量 200-400	B	技術壁壘較強，功能完善，並且用戶指標完成度較高。	B	代碼倉庫較爲規範，相比 alpha 階段進步很大。	4

謎語人隊

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊			β階段日活躍用戶爲40人
髮際線和我作隊	B	不同同學對不同方面問題回答，現場交活躍。	發佈一週後，下載量 200-300，活躍用戶量 50-100	B	增加了聯網、教程，用戶活躍較好。	C	1、CI/測試浮於表面。 2、明文存儲密碼存在較大安全隱患（託庫等）。 3、缺乏對於代碼風格的規範。 4、一方殺後臺時，可導致聯機對象 app 異常，同樣體現了測試的覆蓋不到位。	4
美滋滋甜兮兮隊	A	展示效果佳，現場活躍，回答較完備。	一週後用戶量 300	S	1、對於 alpha 版本中出現的問題均做了有效的修復。 2、推廣效果較好，手段豐富，但最終用戶量未達到預期，是一個遺憾。 3、軟件需求實現較好，功能豐富，整體上圓滿達成目標。	B	1、CI 中使用 root 用戶外部登錄，可能會出現安全性問題。 2、CI 上流程缺失單元測試，但在大數據量上也可以理解。 3、各文檔較爲分離，可上手性不太高。 4、開發過程進度把握較好，記錄詳細。	1
萬里陽光號	C	展示比較單薄，對軟件的整體效果無明顯展示，比較迷惑。	註冊人數 200-300 人，活躍用戶數 100-200	C	1、需求：分析了三個新功能和兩個舊功能對應的需求和改進。 2、日活數據良好，用戶反饋較多。 3、語音功能存在 bug。	C	1、輪值 PM 轉爲指定 PM，使用飛書進行統一管理，有互評保證質量但未堅持。 2、存在文檔和單元測試覆蓋率未呈現在 CI/CD，無 checkstyle 3、測試不充分。	6
是兄弟就來摸魚	B	1、展示時間把握不合理 2、對產品介紹全面	發佈一週內使用次數達到 300	B	1、參加比賽功能較爲新穎，也比較全面。 2、前端界面有待加強。 3、用戶量達標。 4、實現了多學科題庫，可滿足不同學生的需求。	C	1、在開發過程中文檔、測試、代碼規範都有使用，較好。 2、壓力測試未涉及。 3、沒有將各端區分測試。 4、文檔比較混亂，應加強管理。 5、CI/CD 不合理，未起到理想效果。	3
助教團隊	B	1、對產品介紹較完整。 2、視頻無法播放 3、未展示具體效果	一週日活 200，兩週日活 300	C	1、預測功能較爲新穎，但準確度？ 2、與 Google 平臺相比？ 3、可視化不夠完整，性能問題比較嚴重。	D	1、未使用 CI/CD（基本上）。 2、倉庫未分開，分支管理較差。	5
刪庫跑路對不隊	B	1、多個視頻展示，比較豐富。 2、對產品展示較少，缺乏使用產品的展示。	日活用戶爲 400	A	1、產品整體較好，功能較多。 2、在細節處有一些小 bug 和風格不統一。 3、用戶量達標。	B	1、有自動測試且覆蓋率較高，但未作部署。 2、未進行代碼風格測試。 3、文檔全面模塊化。 4、倉庫管理有一定問題 5、測試缺少對 UI/UX 上的測試。	2
蕩起雙槳	C	對產品展示分析較多，效果展示較少。	發佈一週網頁端用戶量 200-400	C	1、產品使用時出現無明確答案的情況。 2、渲染時出現了一部分問題，對分辨率適配不足。	D	1、線下交流較多，issue 粒度較細，使用 wiki 管理。 2、單元測試不充分，缺少風格檢查。 3、出現安全性漏洞，對性能有影響。	7

髮際線和我作隊

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	C	就一個人上來，也沒有視頻 Demo，講解感覺一般	β階段日活躍用戶爲40人	B	對用戶的需求把握可以，需求範圍雖然不廣，但很有針對性，確實能夠滿足一定指標	B	軟件的可擴展性和可維護性沒有看到體現，完全性看來沒有問題，性能應該也沒有問題	6
髮際線和我作隊			發佈一週後，下載量 200-300，活躍用戶量 50-100
美滋滋甜兮兮隊	A	現場展示十分精彩，有很多交互	一週後用戶量 300	A	能夠很好對應影虎需求，且在發佈，推廣上都花了很大功夫，軟件使用效果好，需求指標看來都完成的不錯	A	密碼等都做的十分到位，可靠性有很大的保證，對數據庫保護比較到位，CI/CD 都做的很好，可維護性也很高	2
萬里陽光號	B	有圖文並茂的感覺，效果理想，超時了。	註冊人數 200-300 人，活躍用戶數 100-200	B	在用戶需求方面有一定把握，該產品對市場的吸引程度應該是有的，在軟件的指標完成上較好，基本對提出的需求都進行了滿足	B	在測試上該團隊完成較好，可靠性和安全性都沒有問題，但據說 API 上因爲 bug 做了一些妥協？在文檔和維護上表現一般	3
是兄弟就來摸魚	B	講解比較中肯，感覺講到位了	發佈一週內使用次數達到 300	C	航概題庫是一個面向北航的產品，走出校園、進入市場的可能性有多大呢？對任務的完成性還是較好，軟件效果還行	C	CI/CD 中有很多 Fail，可維護性上雖然有文檔，但實際文檔的可讀性有待商榷，軟件性能不錯，可靠性團隊說是可以	4
助教團隊	C	展示超時，展示表現力尚可，希望多一點豐富的元素	一週日活 200，兩週日活 300	B	需求指標尚可，對於用戶需求，想知道該可視化在市場上的優勢何在。不論競爭，但確實滿足了該領域中存在的用戶需求。	C	助教說近幾小時還在修改？這似乎有點不合適，代碼規範性和可維護性上是否優秀值得商榷，可擴展性也許是有的	5
刪庫跑路對不隊	A	有動畫展示，展示效果好，介紹比較清晰。	日活用戶爲 400	A	對市場把握到位，宣傳盡心盡力，主頁做的很好看，在題庫的數量、範圍，精度上都做的不錯，任務指標完成突出。	A	在安全性上考量比較到位，在大量訪問量之下依舊保證服務的運行，在可靠性上很優秀，在維護性軟件質量上更沒話說	1
蕩起雙槳	B	展示風格大氣，展示內容豐富，展示方面廣泛	發佈一週網頁端用戶量 200-400	D	軟件存在較多明顯 bug，如登入密碼位數提醒錯誤等。問答系統效果較差，測試的簡單問題均未得到合理的回答	C	文檔，可維護性，這些不論。可靠就沒有很好的保證，從功能上無法滿足很多東西，存在部分 bug	7

美滋滋甜兮兮隊

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B	1.無缺席 2.展示性尚可，語速稍快	β階段日活躍用戶爲40人	B	1.主頁比較精緻 2.數據集種類少，內容單一，與科研人員的實際需求不太吻合。 3.日活用戶相對較少	A	1.單元測試，CI/CD 比較完善 2.似乎沒有進行壓測 3.未體現本地軟件運行的效果 4.可展示性、可維護性較好	3
髮際線和我作隊	A	1.無缺席 2.有視頻，效果相對較好	發佈一週後，下載量 200-300，活躍用戶量 50-100	B	1.活躍用戶未達到預期目標，且下載量這個指標不好追蹤 2.不清楚是否滿足了用戶需求。 3.聯機功能很有用，但好像有 bug	C	1.下載方式放在服務器上，易影響性能。 2.似乎無單元測試，CI/CD，壓測 3.註釋較爲完善。 4.聯機測試如何進行？	4
美滋滋甜兮兮隊			一週後用戶量 300
萬里陽光號	B	1.圖片較多，很豐富 2.超時	註冊人數 200-300 人，活躍用戶數 100-200	C	1.未達到日活等預期指標 2.多種模板內容較豐富 3.活躍用戶等定義不清晰 4.用戶需求定義不夠明確	B	1.互評機制不錯 2.進行了 CI/CD 等測試 3.安全性等方面展示不夠充分 4.代碼風格不太理想	6
是兄弟就來摸魚	C	1.有視頻 2.有缺席，人數不足 3.總體效果較好（貢獻分顯示有 7 人實際只有 6 人）	發佈一週內使用次數達到 300	B	1.基本滿足預期需求，CI 界面相對較簡單 2.日活比較詳細，數據較充實 3.總體功能較單一，殺手級功能，感覺缺乏一定實用性	B	1.文檔規範良好，註釋良好 2.CI、CD、單元測試、壓測建議進一步評述 3.未說明軟件的可靠性 4.分支管理建議做進一步完善	5
助教團隊	B	1.無缺席 2.正常完成	一週日活 200，兩週日活 300	A	1.功能完備，各類地圖都有，出行打分功能很贊 2.值傳手段很豐富 3.用戶日活未完全達到預期標準，點擊量這一數據說服較弱	B	1.接口說明文檔很詳細 2.壓測效果比較好 3.未看到 CI/CD、單元測試相關內容 4.安全性未進行說明，數據	2
刪庫跑路對不隊	B	1.視頻很多 2.核心功能未得到充分展示？	日活用戶爲 400	A	1.主頁等 UI 界面設計的比較美觀 2.缺乏用戶對手級功能的實用性反饋 3.用戶數比較多，題庫很豐富	A	1.API 文檔內容比較豐富 2.對環境管理的規範比較弱 3.有 CI/CD、單元測試覆蓋率較高 4.前端熱區比較小？界面風格比較統一？	1
蕩起雙槳	C	1.有缺席，貢獻分顯示有 6 人，實際只有 5 人	發佈一週網頁端用戶量 200-400	C	1.代碼分析，NLP 模型比較有特點 2.註冊等部分適配尚有問題 3.UI 相比 alpha 有比較大改進，但兼容性較弱 4.部分回答的針對性不夠強	C	1.有相應的接口規範代碼 2.單元測試覆蓋率較低，無代碼風格測試 3.風險未知，NLP 魯棒性不足 4.錯誤反饋機制，不清楚在哪	7

萬里陽光號

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B	展示效果較好	β階段日活躍用戶爲40人	B	數據達標，軟件效果良好	A	自動化測試、自動化部署做的較好，可擴展性可維護性較好	4
髮際線和我作隊	C	展示效果一般互動較少感覺是在照念博客	發佈一週後，下載量 200-300，活躍用戶量 50-100	C	需求完成的還行，但展示數據並不能夠充分證明，下載量並未提及，活躍用戶採用人次有點不合理，遊戲下載時速度超級，慢作爲用戶的輕量級顯然很痛苦，下載需 50 分鐘左右一段時間後需 5 小時	C	良好性能，但現場提出的閃退問題以及安全問題仍然存在，後續擴展也還可以，測試並未很充分仍存在少量問題	5
美滋滋甜兮兮隊	A	現場展示效果優秀	一週後用戶量 300	B	需求指標設置不合理，有嚴格要求的設置，所以預期用戶量並不合理，顯然達不到，但滿足用戶需求。	A	網站性能優秀，頁面絲滑，可擴展性更好，後續的持續化手段也很好。軟件的安全性較好，採用加密等多種方式。	1
萬里陽光號			註冊人數 200-300 人，活躍用戶數 100-200
是兄弟就來摸魚	B	現場展示效果良好。	發佈一週內使用次數達到 300	B	註冊用戶、回話等數據基本達標，功能基本滿足用戶需求。	B	測試不完善、文檔部分不完善文檔，更新機制不太合理，還是有一些可以改進的地方。	6
助教團隊	A	現場展示邏輯較爲清晰，互動多。	一週日活 200，兩週日活 300	A	接種點能夠實事解決了用戶的需求，用戶使用人數也基本達標。	B	整體不錯，git commit 不夠規範文檔不夠，後期接手不方便，然後測試覆蓋率較低，不太合規範。	2
刪庫跑路對不隊	A	現場展示效果良好，聲音清晰。	日活用戶爲 400	A	達到預期水平較好的解決了用戶刷題的需求，但是功能還是偏簡單。	B	文檔較爲簡單，後期接手不方便。CI 測試，非常不錯	3
蕩起雙槳	A	現場展示效果良好，用戶交互多。	發佈一週網頁端用戶量 200-400	C	界面美觀挺不錯，但是對大部分問題得到的解答基本無用，用戶使用情況一般。	C	測試還是有一部分的，但是文檔好像沒看見。	7

是兄弟就來摸魚

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	C	1.團隊成員缺席一人。2。現場講解水平尚可。3.互動積極性：只有助教老師	β階段日活躍用戶爲40人	B	需求指標合理；數據真實性：√，軟件效果：中英文問題；指標完成度：在某幾日未完成。	B	軟件性能：高性能；軟件可靠性：系統可保持較高程度持續運行；安全性未發現問題，架構使用現有架構，可維護。	4
髮際線和我作隊	B	1.無缺席，有講解視頻，有助教，老師提問	發佈一週後，下載量 200-300，活躍用戶量 50-100	C	需求；有使用引導；有完成；退出程序可能存在問題	D	直接在服務器上發佈下載；安全性問題：密碼存儲明文；代碼管理存在問題	7
美滋滋甜兮兮隊	A	無缺席；有詳盡的解釋視頻；互動優良，聽的清。	一週後用戶量 300	A	拼寫單詞功能有創新點，用戶量爲 250 人左右，未達到目標。	S	石墨文檔加 gitlab issue；前後端分離；文檔代碼解耦；團隊管理，線下開發，測試完備；安全性可能存在問題	1
萬里陽光號	B	無缺席，互動一般	註冊人數 200-300 人，活躍用戶數 100-200	B	畫面較爲美觀，有靜態教程；殺手級功能效果一般；達到需求指標，需求指標本身含混且較低	D	進行了基本測試，算法存在問題，只採用一個分支進行開發，單元測試覆蓋率不足，代碼風格不可以	6
是兄弟就來摸魚			發佈一週內使用次數達到 300
助教團隊	B	無缺席，解釋視頻未展示，語速合適。	一週日活 200，兩週日活 300	A	基本達到需求目標，需求目標較爲合理，功能較爲合理，數據修復。	B	CI/CD 存在問題,無實質性內容，Git 版本管理較差。	3
刪庫跑路對不隊	A	無缺席，有動畫視頻，互動很好	日活用戶爲 400	A	需求達到目標，需求高標準。	A	多分支開發。環節管理存在問題，文檔安排存在問題。	2
蕩起雙槳	A	無缺席，聽得清。	發佈一週網頁端用戶量 200-400	B	功能較好，採用對話形式，模板形式，需求完成	C	線下交流與開發無法返回消息，功能存在問題，安全性存在問題。	5

助教團隊

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	A	展示比較全面，問題的回答也比較流利。	β階段日活躍用戶爲40人	B	相比 alpha 階段，功能的完整性和全面性都有很大的提升，對目標需求的滿足較好。	B	使用了 CI 工具，進行了單元測試並有自動部署功能。軟件的文檔也比較完整。	3
髮際線和我作隊	B	展示效果較好，時間控制的也不錯，但問答有些不流暢。	發佈一週後，下載量 200-300，活躍用戶量 50-100	B	遊戲的可玩性有了很大提高，並新增了聯機功能，用戶量基本完成目標，日活量較低。	B	軟件的測試上被指出了一點問題，但總體的成果還行。版本控制做的不錯，值得學習。	4
美滋滋甜兮兮隊	A	展示效果不錯，對問題的回答也很流利	一週後用戶量 300	A	軟件效果很好，宣傳工作做得很不錯，但是日活數量相比不是很高。軟件的概念很新穎，界面的設計也很美觀。	A	測試工作做的非常完備，軟件的總體質量很高，軟件的可靠性不錯。雖然助教指出了一些問題，但總體完成度很高。	1
萬里陽光號	C	展示時間掌握的一般，整體效果尚可，對問題的回答稍有卡頓	註冊人數 200-300 人，活躍用戶數 100-200	C	用戶量達成目標，功能相比 Alpha 就有了很大完善，界面設計也豐富了很多，但美觀性可以再提升。	B	做了一定的 CI/CD 工具的使用，測試工作還不夠完善。軟件性能不錯，使用比較流暢。	6
是兄弟就來摸魚	B	軟件使用效果介紹的比較全面，詳略比較得當。	發佈一週內使用次數達到 300	C	功能進一步完善，用戶量基本達標，使用中存在一些明顯的 bug，加載速度也比較慢。	C	測試工作做得不夠完善，文檔的管理也有些混亂，但總體的結果完成度尚可。	7
助教團隊			一週日活 200，兩週日活 300
刪庫跑路對不隊	B	項目展示良好，對問題的回答較好，可以禮貌一些，不打斷他人講話更好。	日活用戶爲 400	A	軟件完成度較高，宣傳工作做的很充分，日活用戶達標，測試工作完成度高，有一些沒有考慮到用戶體驗的地方但整體不錯。	A	使用了 CI 工具，進行單元測試並自動部署功能。有專門的反饋羣並經常更新軟件修復 bug。	2
蕩起雙槳	A	項目展示較好，現場講解表述清除，問答時多位成員都與現場進行了互動。	發佈一週網頁端用戶量 200-400	C	平臺活躍用戶數較少，應加大宣傳力度，且用戶反饋較少；在軟件使用方面，問答的準確度及範圍可以進一步增大。	B	使用了 CI 進行單元測試，且進行了代碼分析，管理方面比較完備，交互記錄部分做得也比較好。	5

刪庫跑路對不隊

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B	存在缺席	β階段日活躍用戶爲40人	B	需求指標很低且只完成 90%的需求指標，可以解決用戶需求	B	性能方面無具體說明，對可靠性與安全性的要求有待提高，部署了 CI 以及進行了單元測試可靠性高。	2
髮際線和我作隊	A	表達清晰，有熱情。	發佈一週後，下載量 200-300，活躍用戶量 50-100	B	日活指標未達到。需求指標合理且有挑戰，用戶真實，可以解決用戶需求，但 UI 界面小，實現困難具有挑戰性	A	作爲遊戲開發，量級控制較好，性能與可靠性達到一定要求，安全性有待提高以及代碼風格需要完善統一。	3
美滋滋甜兮兮隊	B	視頻聲音卡	一週後用戶量 300	A	需求合理且具有挑戰性，但利用 PCA4 記憶效果遠不如紙質 A4 記憶效果，實際用戶也說明此問題。	A	對於量級優化不夠，對於項目管理上進行了一定優化。對於測試方面，不夠完善，但在安全性上進行較大的投入。	4
萬里陽光號	B	展示效果一般。部分內容未說明如性能可靠性。	註冊人數 200-300 人，活躍用戶數 100-200	B	需求合理單目標活躍用戶估計不到 50%，展示使用點擊次數近似日活不合理。	B	在性能處理較好，未說明其對安全性可靠性的處理方案，部署了 CI/CD，有較爲規範的代碼規範。	6
是兄弟就來摸魚	B	展示效果一般。部分內容爲說明如性能可靠性。	發佈一週內使用次數達到 300	C	需求合理，達到使用人數，但發佈的功能來看打卡不是必須的，且只是另一個小程序的子集。	C	功能單一，UI 設計與先前產品（航概題庫）高度相似，測試較少，安全性較 Alpha 有所提高，但依舊欠缺。	7
助教團隊	B	展示效果一般，不夠激情。	一週日活 200，兩週日活 300	A	需求較爲合理，在疫情後期有一定需求。前端頁面較爲美觀簡潔，雖然需求指標達標，但考慮宣傳受衆，可以理解，功能完成度較高。	A	功能在需求前提下完成度高。對於數據處理到位。可靠性與安全性的答理較爲完善。代碼規範也較爲到位，但管理存在一定問題。	1
刪庫跑路對不隊			日活用戶爲 400
蕩起雙槳	A	展示效果良好，對產品重點突出到位，展示有激情。	發佈一週網頁端用戶量 200-400	B	需求較合理，達到了使用人數，從軟件使用上，對於 AI 回答，完成效果不太好，另一方面前端交互方式不太友好。	C	測試不到位，採用技術較爲先進，但對於模型訓練，數據集有所欠缺，前端頁面較爲普通，不太支持多種瀏覽器，但代碼規範較好。	5

蕩起雙槳

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B		β階段日活躍用戶爲40人	B	軟件具有良好的 UI，但關鍵功能（個人認爲）即提供的數據數量有點少，任務難度也沒有太體現。	A	團隊配置了完善的 CI，包括測試、發佈與部署等，且團隊有統一的 PM 對團隊進行管理與協調。	4
髮際線和我作隊	B		發佈一週後，下載量 200-300，活躍用戶量 50-100	B	軟件效果從展示來看還可以，但以 APK 形式發佈軟件（且較大）仍是一個弊病。	C	首先正如助教所說，程序存在一定的安全性問題，且軟件的單元測試與代碼質量在展示中體現的也不完善。	5
美滋滋甜兮兮隊	A		一週後用戶量 300	S	團隊對用戶指標的定義很明確，且軟件整體確實有很好的效果，提供的功能也很完善。	B	通過多個倉庫實現前端、後端、接口的分離，管理清晰，但是存在明文密碼打印至日誌、root 運行服務器程序等問題，CI 未運行單元測試。	2
萬里陽光號	B		註冊人數 200-300 人，活躍用戶數 100-200	C	就使用來說，雖然小程序提供了豐富的模板，但就實際使用情況來說用手機輸入數據有些太不方便了，導致實際的使用體驗不是特別好。	A	單元測試覆蓋率較高，但與 CI 的配合較混亂。利用飛書增強項目管理。	7
是兄弟就來摸魚	B		發佈一週內使用次數達到 300	B	軟件提供了刷題、比賽、打卡等功能，對處於需要軍理、航概題庫中刷題的人來說很有用，但適用人羣還是很有限。	C	CI 存在 fail，但刻意通過調整 CI 腳本使得 CI 通過，掩蓋錯誤。	6
助教團隊	A		一週日活 200，兩週日活 300	A	在特殊時期下，這個網站提供的信息顯得較其他項目來說有用得多，且提供的信息類型也比較全。	B	利用 CI 進行單元測試，工作進度沒有及時以書面形式記錄下來，issue 進用較簡陋。	3
刪庫跑路對不隊	A		日活用戶爲 400	A	團隊的首頁比較驚豔，且同時提供了程序與 APP。此外提供的題庫也不侷限於航概，提高了受用性。	S	前後端均有 CI 單元測試，代碼規範，覆蓋率較高，並且進行了壓力測試。	1
蕩起雙槳			發佈一週網頁端用戶量 200-400

大衆評審團 1

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B	展示邏輯清晰，要點明確，但缺乏互動	β階段日活躍用戶爲40人	A	技術難度，實現難度合理。需求剖析合理，殺手級應用完善，但對比競品尚缺關鍵優勢 UI UX 不夠直觀	A	1、產品經過了充分、完整 的測試 2、產品分工、開發流程合理； 3、性能優化優秀可見功夫； 4、代碼架構優秀，維護性好	2
髮際線和我作隊	B	展示邏輯清晰、有條理，多媒體展示優秀	發佈一週後，下載量 200-300，活躍用戶量 50-100	B	需求分析合理，目標用戶完善，軟件質量及技術難度合理，初級遊戲雛形，團隊有持久運的合理考慮	B	1、密碼安全性存在漏洞，有顯見的信息安全風險，但團隊進行了相應的考慮 2、優化仍存在問題，安裝包過大	6
美滋滋甜兮兮隊	A	展示邏輯清晰，條理清楚，有吸引力，有說服力	一週後用戶量 300	S	1、功能完善優秀，反饋合理 2、易用性、性能、用戶友好度優秀，功能亮點多，實績號 3、推廣考慮完整，收效甚優	A	1、項目分工合理，成員貢獻優秀；輪值 PM 機制合理； 2、項目管理流程符合標準，單元測試流程完善取捨合理	1
萬里陽光號	B	展示邏輯清晰，但交互性較差，猶如念稿	註冊人數 200-300 人，活躍用戶數 100-200	C	1、功能不清晰，需求分析不明確，目標用戶不明朗； 2、活躍用戶數據統計方式有問題，存在疑問，量度不佳	B	1、項目管理存在齟齬，分工比較明確，但 workflow 存在問題； 2、倉庫、分支、提交管理有問題 3、測試緩解考量不完善	8
是兄弟就來摸魚	A	展示邏輯清晰，多媒體運用合理	發佈一週內使用次數達到 300	A	1、需求解析優秀、交互合理； 2、精確瞄準用戶需求，好用易用，功能取捨合理 3、宣傳得宜，效果優秀，覆蓋面廣	B	1、項目管理有部分問題 commit message 存在齟齬 2、單元測試存在較大問題 3、CI 利用不合理 4、文檔書寫不合理	3
助教團隊	B	展示清晰但缺乏交互	一週日活 200，兩週日活 300	B	1、需求把握合理，考慮到位 2、精到、精緻地確定了需求的範圍，使產品切中肯綮 3、影響推廣思路清晰合理	B	1、項目管理多有可指摘之處 2、開發流程管理混亂，commit message 不充分 3、CI 利用亦存在問題	5
刪庫跑路對不隊	A	展示邏輯合理，藉助視頻優勢。	日活用戶爲 400	B	1、項目展示邏輯美觀 2、覆蓋需求廣泛，但缺乏針對性優化，交互頗有問題	S	項目管理流程優秀且完善	4
蕩起雙槳	A		發佈一週網頁端用戶量 200-400	C		B		7

大衆評審團 2

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B	展示順序可優化，功能展示部分操作過快	β階段日活躍用戶爲40人	A	1.軟件 UI 好看，展示效果良好 2.交互良好流暢，新手使用無障礙 3.做出了差異化（用戶友好、初學者友好），完成了需求指標	A	1.有完整的測試流程（單元測試、CI) 2.沒有出現安全性方面的問題 3.CI 上的測試流程較完善。包括代碼規範等	2
髮際線和我作隊	B	可以模仿遊戲宣傳片，邏輯不夠清晰	發佈一週後，下載量 200-300，活躍用戶量 50-100	B	1.沒有玩法/畫面上的創新。同質化較高，缺少吸引用戶的要素 2.UI 顯示上有一些小問題，使用流程上存在問題（強制退出）	C	1.安裝包過大，沒有壓縮素材 2.密碼明文存儲，存在安全性問題 3.測試流程不夠完善 4.沒有 ignore 緩存文件等	6
美滋滋甜兮兮隊	A	展示邏輯清晰，時間安排合理	一週後用戶量 300	S	1.界面簡潔，用戶體驗良好，功能豐富，使用直觀 2.完成度非常高，對競品差異化大	B	1.軟件架構清晰，擴展性強 2.存在潛在的安全性問題	1
萬里陽光號	B	層次邏輯清晰，演講時間安排可以改善	註冊人數 200-300 人，活躍用戶數 100-200	C	1.用戶體驗一般，UI 有待優化 2.沒有做出區分度，和已有的競品相比沒有競爭力	B	1.測試流程完善，但缺少風格檢查 2.項目管理清晰	7
是兄弟就來摸魚	B	講解比較沉悶，沒有條理	發佈一週內使用次數達到 300	A	1.成就係統比較新穎 2.UI 有待優化	B	1.CI 配置中有缺陷 2.安全性、可靠性上沒有發現明顯的問題	4
助教團隊	B	層次邏輯不清晰，時間安排不合理	一週日活 200，兩週日活 300	B	雖然有競品對比，但感覺競爭力不大。特別是已有的常用 app 都有類似功能	B	1.commit message 信息可以改善 2.CI 部署不夠完善	3
刪庫跑路對不隊	B	層次邏輯不清晰	日活用戶爲 400	B	產品和官網顯示效果有區別（UI 等方面），需要改進	B	缺少代碼風格方面的檢查（CI）	5
蕩起雙槳	B	演講時間安排不合理，缺少關鍵部的展示	發佈一週網頁端用戶量 200-400	C	1.適配上存在問題（自適應） 2.問題集數量少。使用體驗上比較差，經常找不到相關數據	B	CI 上有些不完善，缺少代碼風格測試	8

大衆評審團 3

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B	人員是否存在缺席不明，認爲無無故缺席。	β階段日活躍用戶爲40人	A	不太懂深度學習這一塊，從展示效果上看可以解決用戶需求，基本完成了需求指標。	A	進行了一些黑箱測試，沒有發現明顯問題，進一步閱讀代碼沒有找到明顯的安全問題，可讀性較好。	3
髮際線和我作隊	B	可以確定人都到齊了。	發佈一週後，下載量 200-300，活躍用戶量 50-100	B	功能正常，相比 Alpha 有一定進步，不過小人對砍等問題還是未解決。此外文件還是太大。	C	存在 apk 放倉庫，明文存儲用戶密碼的問題，雖然使用了 HTTPS 保護但是個人認爲還是不夠安全。	6
美滋滋甜兮兮隊	A	可以確定人都到齊了，有比較好的互動。	一週後用戶量 300	A	軟件效果優秀，功能較爲強大，完成了需求指標，雖然個人不太喜歡這種背詞方式，但不可否認軟件挑戰性和優秀性。	A	有較好的安全性，倉庫的設置比較合理，雖然存在包括後臺 print 密碼等行爲但同樣不可否認其優秀性。	1
萬里陽光號	B	可以確定人都到齊了。	註冊人數 200-300 人，活躍用戶數 100-200	C	軟件效果一般，界面不夠美觀，可以解決部分用戶需求，語言識別算法不夠準確，基本完成需求指標。	C	後端基於 Java，架構尚可，前端基於微信，安全性算是有保障，進行了測試，但覆蓋和數據強度不足。	7
是兄弟就來摸魚	B	可以確定人都到齊了。	發佈一週內使用次數達到 300	B	軟件效果尚可，比較不錯的一點是有軍理題庫，感覺測試進行的不夠充分，基本完成了需求指標。	B	一個可能的隱患是沒有限制反饋文本的大小，可能會被卡，由於前端基於微信，安全性尚可。	5
助教團隊	B	可以確定人都到齊了。	一週日活 200，兩週日活 300	B	界面比較美觀，對各平臺都有較好的適配，不過修改分辨率後刷新纔可見，基本解決需求指標。	B	沒留用戶登錄等接口，自然有很高的安全性，對反饋信息等進行了校驗，感覺沒啥硬傷。	4
刪庫跑路對不隊	B	可以確定人都到齊了。	日活用戶爲 400	A	功能強大，很好地完成了需求和指標，唯一不爽的是單選和多選，的確作者有自己的考慮，單個人認爲加一項設置更好。	A	使用 HTTPS，基於微信小程序作爲前端，有較好的安全性，（看代碼發現 alpha 或有 sql 注入漏洞？）	2
蕩起雙槳	B	可以確定人都到齊了。	發佈一週網頁端用戶量 200-400	C	Windows 下無法加載，Linux 下加載成安卓的響應式，用起來比較卡，且回答的準確性不足。	C	存在安全隱患，刷新時加載全部提問信息又不限制單個信息的大小或信息數量，可能被惡意提問導致他人加載時卡在獲得提問上。	8

大衆評審團 4

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B		β階段日活躍用戶爲40人	B	最終實現效果比較完整。圖片展示效果在配色上稍有不滿。整體還挺不錯。	A	分支管理 CI Milestone 用得不錯，git 倉庫也比較趕緊，無大瑕疵	3
髮際線和我作隊	B		發佈一週後，下載量 200-300，活躍用戶量 50-100	C	教程做的不完整？按鈕 UI 風格不一致。“你已選擇”有顯示 bug。	C	SSL 私鑰放入倉庫__pycache__Log Temp 明文存密碼	6
美滋滋甜兮兮隊	A	不愧是 OO 助教團隊，演講很強	一週後用戶量 300	S	美觀，功能強大，可以看出下了不少功夫來做，前途可期	A	模塊化分離開發 輪值 PM 密碼安全出現瑕疵 分支名不太好，PR 不太對	1
萬里陽光號	B		註冊人數 200-300 人，活躍用戶數 100-200	C	Bug 多，測試不足，前端圖片作按鈕 滾動不按頁，都不太好看	C	大量 DS_Store, log_IS_UNDEFINDED 證書文件	8
是兄弟就來摸魚	B		發佈一週內使用次數達到 300	B	從α->β開發了小程序並有這樣的完成是非常不容易的，不過UI方面設計和交互仍有欠缺	C	failure 直接忽略過 CI 傳了，idea 文件夾	5
助教團隊	B		一週日活 200，兩週日活 300	A	還有一點顯示上的問題沒有處理好，如字色、圖示，左下角數沒單位，功能上很豐富，手機端適配	B	CI 沒有用嗎？別的也看不出什麼問題	2
刪庫跑路對不隊	C	好剛啊 上場要謙虛！	日活用戶爲 400	B	考期日曆沒什麼用，主刷題功能用戶操作沒有太多改進，操作不如 IOS 版的，β階段看不出太多改進	A	沒大毛病 SSL 私鑰傳到倉庫裏不好	4
蕩起雙槳	B		發佈一週網頁端用戶量 200-400	C	不太好用，不太有用，只能說沒有功勞也有苦勞。只能說項目完全不明確	B	安全問題又被打了 build 文件夾不應上傳，倉庫只有一個	7

大衆評審團 5

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B	有一人未到，展示後期略倉促	β階段日活躍用戶爲40人	B	日活用戶數未達到總指標，指標不太合理，主頁視覺效果好，網頁操作方便，應用場景較廣，標籤很用戶友好，本地端功能較爲完整，但網頁端功能不太全面	A	軟工採用的工具較多，應用了 docker 等開發工具，gitlab ci 等工具應用合理（仍有提升空間），團隊分工明確，內部文檔，代碼規範等較好	5
髮際線和我作隊	A	時間控制較好，有視頻且製作精美，講解較詳細	發佈一週後，下載量 200-300，活躍用戶量 50-100	B	遊戲設計較好，沒什麼大問題，有教程，對新手友好，指標基本達到，較合理，界面有美化空間	C	明文密碼存儲，安全性問題較爲嚴重。 alpha-beta 階段有改進，測試不太充分	6
美滋滋甜兮兮隊	A	視頻講解佔展示時間較長，宣傳效果好，演講同學聲音清晰，有互動	一週後用戶量 300	S	功能較爲豐富，指標未完成（電腦背單詞的需求量可能不大），界面美觀，對背單詞的視覺刺激較好，功能完善，有社區等，發展空間大，詞圖創意好	A	團隊管理較爲明確，API 文檔豐富，線下開發效率較高，但組織形式有提升空間，系統功能架構較複雜，模塊分解開發較好	1
萬里陽光號	B	展示超市，有使用方法的動畫展示	註冊人數 200-300 人，活躍用戶數 100-200	C	教程頁面進入小程序按鈕不太明顯，需向下翻頁（這點不太好），需求較少，指標未達到，實用性一般	C	存在一些功能上的 bug，團隊管理模式責任落實的較好，CI 使用存在一些問題，gitignore 未 ignore 掉:Ds_store。commit 記錄有點模糊	7
是兄弟就來摸魚	A	講解展示較清晰	發佈一週內使用次數達到 300	B	活躍度目標達到了預期，功能完整性還行，打卡等成就機制、錯題等功能很完整，完成度高	B	文檔有點混亂，只有一個倉庫，CI/CD 使用存在不當（很多 fail）	4
助教團隊	B	演講超時，比較清晰詳細	一週日活 200，兩週日活 300	A	日活指標基本完成，使用體驗還可以，數據展示比較清晰實用完成度比較完整	B	最後一次 CI 未通過（mysql 啓動未成功），分工、進度控制等還可以	3
刪庫跑路對不隊	A	動畫製作精美，講解上有些粗糙	日活用戶爲 400	A	訪問量達到標準，功能完整，社區機制完整，界面精美	A	Ci 未進行風格測試，安全性好，API 文檔完整，模塊化	2
蕩起雙槳	A	展示很詳細清晰	發佈一週網頁端用戶量 200-400	C	較好完成了需求指標，界面美觀程度有待提高，使用效果，回答準確率較低，適配不充分，使用價值不高	B	單元測試覆蓋率不高，CI、文檔等較完善	8

大衆評審團 6

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B	講解略顯倉促，沒有突出重點，總體不錯	β階段日活躍用戶爲40人	B	指標較爲合理，且軟件效果較好，界面美觀人性化，但是日活指標未達到	B	團隊分工較爲合理，CI/CD 流程優秀，代碼檢查嚴格，進行了多平臺的測試	5
髮際線和我作隊	A	講解較爲詳細，有視頻展示環節，有一定的互動	發佈一週後，下載量 200-300，活躍用戶量 50-100	C	指標合理且具有挑戰性，基本圓滿完成，但界面和動畫效果仍需要一些打磨，設計上存在不夠人性化的地方	B	使用明文密碼，安全性存在問題？ 對 git 的使用和管理較好，測試較爲完備	6
美滋滋甜兮兮隊	A	錄音講解有一點模糊，講解有點倉促，但基本清晰	一週後用戶量 300	A	需求指標合理，在完成了背詞網頁界面優美等基本需求之後，也完成一定的興奮需求（如詞圖），指標達成情況一般，完成度高，詞庫量大	A	對用戶密碼管理存在泄露可能。用看板方式協同開發較好，對多場景都進行了測試，文檔豐富	2
萬里陽光號	B	講解比較清晰，有小程序功能的演示，展示超時	註冊人數 200-300 人，活躍用戶數 100-200	B	需求指標合理，預期目標完成度高，自動導入功能較爲方便，但圖標類型較少，不能完成用戶需求	C	對 API 的使用缺乏測試，遺留了較爲影響用戶體驗的 Bug，測試不夠完善，團隊溝通對接模式完整	7
是兄弟就來摸魚	A	講解清晰，功能演示完善	發佈一週內使用次數達到 300	B	需求指標略低，但完成度超越指標較多，實現了刷題軟件所需的大部分功能和成就鼓勵機制	B	實現了前後端的分離，成員分工較爲合理，文檔規範還有待提高，CI/CD 測試有遺留問題	4
助教團隊	A	講解清晰，功能直接明瞭	一週日活 200，兩週日活 300	S	需求指標較有難度，但完成度較好。界面美觀，功能完善，完成了多個平臺的適配，各種數據得到了直觀展示對錯誤數據應對有缺陷	A	團隊分工合理，對文檔的管理較爲合適，最後一次 CI 測試沒有通過	1
刪庫跑路對不隊	B	講解過於簡單，沒有涉及到優勢，但宣傳片等部分較好	日活用戶爲 400	A	日活較有挑戰性，達成情況一般，但有時間因素，網頁和小程序界面設計較爲精美	S	代碼風格沒有嚴格測試，有較好的安全性，文檔管理全面規範	3
蕩起雙槳	A	講解詳細，能夠突出重點和優勢，整體效果較好	發佈一週網頁端用戶量 200-400	C	需求指標合理有挑戰性，達成情況一般，功能新穎但是部分功能有缺陷，界面美觀，使用體驗一般	C	有完整的前後端代碼規範和文檔，CI/CD 測試較爲完善，在不同平臺上出現了適配的問題	8

大衆評審團 7

待評審小組	現場展示質量		軟件質量			軟工質量		綜合排名
	評級	理由	需求指標	評級	理由	評級	理由
謎語人隊	B	有缺席	β階段日活躍用戶爲40人	A	日誌輸出密碼	A	優秀的 CI 使用（pylint +unittest+server deploy）；並有壓力測試和不同部署平臺的相關測試。	2
髮際線和我作隊	B		發佈一週後，下載量 200-300，活躍用戶量 50-100	B	明文密碼存儲	C	測試單薄，代碼風格無檢查。	6
美滋滋甜兮兮隊	A		一週後用戶量 300	A	日誌輸出密碼，服務器用 root 密碼登錄。	B	代碼倉庫整體問題。	3
萬里陽光號	B		註冊人數 200-300 人，活躍用戶數 100-200	B		C	矩陣測試只有表格，臨近 ddl 才做測試，大量冗餘文件，無代碼風格測試。	8
是兄弟就來摸魚	B		發佈一週內使用次數達到 300	B		C	屏蔽錯誤，先部署後測試。	7
助教團隊	B		一週日活 200，兩週日活 300	B	有出行指標推薦，整好很多數據源，但因爲國內數據相關問題，存在實用性問題，無法應用數據修改。	C	擴展性問題，大量冗餘文件，假 CI，混亂的 commit message，但有一定的 bug 管理。	5
刪庫跑路對不隊	A		日活用戶爲 400	A		A		1
蕩起雙槳	A		發佈一週網頁端用戶量 200-400	B	神經網絡數據範圍優先。	B	無依賴庫 list 文件夾命名 無神經網絡測試 代碼風格	4

總體結果

現場評審部分助教們所給出的結果爲

待評審小組	助教 1	助教 2	助教 3	助教 4	助教 5	總和	排名
謎語人隊	2	3	3	1	3	12	3
髮際線和我作隊	5	6	4	8	5	28	5
美滋滋甜兮兮隊	1	2	1	2	2	8	1
萬里陽光號	8	8	6	7	7	36	8
是兄弟就來摸魚	6	5	8	6	8	33	7
助教團隊	3	4	5	4	6	22	4
刪庫跑路對不隊	4	1	2	3	1	11	2
蕩起雙槳	7	7	7	5	4	30	6

小組互評結果爲

待評審小組	謎語人隊	髮際線和我作隊	美滋滋甜兮兮隊	萬里陽光號	是兄弟就來摸魚	助教團隊	刪庫跑路對不隊	蕩起雙槳	總和	排名
謎語人隊		6	3	4	4	3	2	4	26	4
髮際線和我作隊	4		4	5	7	4	3	5	32	5
美滋滋甜兮兮隊	1	2		1	1	1	4	2	12	1
萬里陽光號	6	3	6		6	6	6	7	40	7
是兄弟就來摸魚	3	4	5	6		7	7	6	38	6
助教團隊	5	5	2	2	3		1	3	21	3
刪庫跑路對不隊	2	1	1	3	2	2		1	12	1
蕩起雙槳	7	7	7	7	5	5	5		43	8

大衆評審團所給出的結果爲：

待評審小組	評審團 1	評審團 2	評審團 3	評審團 4	評審團 5	評審團 6	評審團 7	總和	排名
謎語人隊	2	2	3	3	5	5	2	22	3
髮際線和我作隊	6	6	6	6	6	6	6	42	6
美滋滋甜兮兮隊	1	1	1	1	1	2	3	10	1
萬里陽光號	8	7	7	8	7	7	8	52	8
是兄弟就來摸魚	3	4	5	5	4	4	7	32	5
助教團隊	5	3	4	2	3	1	5	23	4
刪庫跑路對不隊	4	5	2	4	2	3	1	21	2
蕩起雙槳	7	8	8	7	8	8	4	50	7

現場評審部分最終結果爲

待評審小組	助教意見	互評意見	大衆評審意見	總和	總和排名	折算分數	排名
謎語人隊	12	26	22	60	3	45	3
髮際線和我作隊	28	32	42	102	5	40	5
美滋滋甜兮兮隊	8	12	10	30	1	50	1
萬里陽光號	36	40	52	128	8	36	8
是兄弟就來摸魚	33	38	32	103	6	40	6
助教團隊	22	21	23	66	4	44	4
刪庫跑路對不隊	11	12	21	44	2	48	2
蕩起雙槳	30	43	50	123	7	37	7

共計分爲三檔，在統一檔內分數按照總和差異線性映射，依次是：

1. 第一檔：刪庫跑路對不隊、美滋滋甜兮兮隊
2. 第二檔：謎語人隊、助教團隊
3. 第三檔：髮際線和我作隊、是兄弟就來摸魚、萬里陽光號、蕩起雙槳

複審評分

評審規則

複審部分的評分規則爲分爲以下四個部分：

• 軟件的質量，具體來說軟件應符合用戶的需求，且有實際的數據來證明用戶的需求確實被滿足了（40 分）
  • 預訂目標合理性（10 分，並決定完成度權重）
    • 預定目標完全合理，具備足夠的挑戰性，令人期待——10分，係數1.0
    • 預訂目標基本合理，符合北航大三學生應有的水準——8-9分，係數1.0
    • 預訂目標勉強合理，給人比較保守的感覺——6-7分，係數0.8
    • 預訂目標不合理，但仍有基本的標杆在——3-5分，係數0.6
    • 預訂目標很荒唐，完全不重視也不想認真對待——0-2分，係數0.2
  • 預訂目標完成度（30 分，最終分數會再乘上面所說的係數）
    • 預訂目標圓滿完成（原則上不低於 95%），用戶評價優秀——26-30分
    • 預訂目標基本完成（原則上不低於 85%），用戶評價良好——22-25分
    • 預訂目標勉強完成（原則上不低於 70%），用戶評價尚可——18-21分
    • 預訂目標較多未完成，但仍有部分完成（原則上不低於 35%），並且面對了用戶——10-18分
    • 預訂目標基本未完成（低於 35%），並且面對了用戶——1-10分
    • 預訂目標基本未完成，並且未面對用戶——0分
    • 在目標基本合理及以上的情況下，較高幅度地超額完成目標（原則上至少超額 200%以上），或跳出了課程本身做出了長遠性質的成果（如廣泛傳播的開源、獲得了真實的投資等）——酌情額外加分1-5分
    • 預訂目標完成情況經覈實存在數據造假、謊報、拒不配合、阻撓審覈等情況——無條件0分計，無視以上全部得分，並保留進一步追究其他學業不端行爲的權力
    • 上述分數均需要按照預訂目標合理性的係數進行打折
• 過程的質量，具體來說軟件應是整個團隊按照一定的軟件流程共同努力開發出來的，有相關的證據和記錄展現（15 分）
  • Gitlab 使用規範性（5 分）
    • 較爲完整的使用了 Gitlab Issue/Milestone 等一系列功能，並且充分利用功能特性在 Gitlab 上展開討論與協作，且 Gitlab 組織結構合理——5分
    • 較爲完整的使用了 Gitlab Issue/Milestone 等協作類功能，但 Issue 上記錄不完整或討論極少，組織結構存在少量問題（例如倉庫規範性上的小問題）——3-4分
    • Issue/Milestone 等功能使用偏少且較爲蒼白，組織結構存在較大問題（例如沒有合理分倉庫或開啓後未使用等情況）——1-2分
    • Issue/Milestone 等功能幾乎沒有使用，也沒有多少維護——0分
  • 團隊協同配合程度（5 分）
    • 團隊內部配合高度默契，成員安排有亮點，協作得以高效推進——5分
    • 團隊內部配合較好，成員安排合理，協作得以有序推進——3-4分
    • 團隊內部配合尚可，有較多不當之處，但協作得以勉強維持——2分
    • 團隊內部配合欠佳，普遍存在消極怠工、內部矛盾等情況，協作難以推進——1分
    • 團隊內部幾乎無配合，較多存在成員獨走、單幹等情況——0分
  • 博客互動程度（5 分）
    • 對課程組的點評一直有及時而積極地互動與討論，問題修復及時——5分
    • 大部分情況下對課程組的點評有積極迴應，並且對問題有及時的修改與反饋——3-4分
    • 時常不迴應、消極迴應、很慢迴應評論，並且對指出的問題存在不配合或拖拉情況——1-2分
    • 經常性不迴應或很久纔回應評論，並且對指出的問題不加修改和反饋——0分
    • 有過一次或多次博客精彩討論——酌情額外加1-2分，需要指明精彩討論之處
• 工程的質量，具體來說軟件應是可維護和擴展的，並且有充分的數據和證據來展現（30 分）
  • 性能水準（5 分）
    • 定位爲產品的性能，以及數量意義上的抗壓能力。
    • 經過實測，全功能均可以承受需求指標高出至少一個數量級的壓力——5分
    • 經過實測，核心功能可以承受需求指標高出至少一個數量級的壓力，其餘功能均可以承受需求指標同數量級的壓力——4分
    • 經過實測，核心功能可以承受需求指標同數量級的壓力，其他功能可以承受基本的壓力——3分
    • 經過實測，核心功能可以承受一定壓力，但是無法保證能滿足需求指標需要——1-2分
    • 性能水準未進行實測，或實測信息無法證明最基本的性能——0分
    • 如有測試報告存在僞造等行爲——無條件倒扣5分，並保留進一步追究其他學業不端行爲的權力
  • 可靠與穩定性水準（5 分）
    • 定位爲產品的可靠性與穩定性，即產品可以保證多大覆蓋面上的可用。
    • 產品可以保證持續的可用，在基本約束限制下的任何情況都可以保持正常提供服務——5分
    • 產品可以保證基本的可用，在基本約束限制下的絕大部分情況可以正常提供服務，不會出現系統級別的停機，且在出現小問題時可以快速地恢復正常不會影響主要業務（例如出現異常後可以引導用戶快速跳出並重新開始）——4分
    • 產品可以保證基本的可用，在基本約束限制下的大部分情況可以正常提供服務，在出問題時需要進行有限度的的維護才能維持運行，存在少量足以影響主要業務的問題（例如驗證碼發送失敗將導致用戶被卡死在這一步無法前進也無法後退）——3分
    • 產品經常性出現不可用的情況，經常性需要系統維護，存在較多足以影響業務的問題——1-2分
    • 產品幾乎無法保證可用——0分
  • 安全性水準（5 分）
    • 定位爲產品的安全性，即保證用戶數據安全以及系統本身安全的能力。
    • 安全性整體優秀，難以找到足以造成實質後果的安全性問題——5分
    • 安全性整體良好，存在一些安全性上的不足之處（例如對爬蟲限制過弱、未配備 https 等），或存在少量且不算嚴重的安全性問題（例如少量非關鍵用戶數據可以被預期外的方式獲取、可以通過特定操作穩定造成系統整體波動等）——2-4分
    • 存在嚴重的安全性問題，可以造成系統服務崩潰、關鍵權限非法獲取、用戶數據大量泄露等嚴重後果——0-1分
    • 特別說明一下安全性測試的界限
      • 不要進行根本上依賴於大量資金等外部資源投入的安全測試，例如
        • DOS 攻擊測試要注意限度，因爲對強力 DOS 的防禦主要靠的還是防火牆、CDN、服務器計算資源與帶寬等資源投入量
        • 不要進行 DDOS 攻擊，因爲對 DDOS 的有效防禦很難靠小團隊力量完成，主要還得靠雲平臺的系統安全服務支持
      • https 應該算是標配，不然在現在的移動應用環境下，先抓包再重放，或者再順道劫持一下客戶端，就足以讓接口淪陷
      • 服務器/數據庫的弱口令登錄、sql 注入、抓包重放等算是基本操作，屬於必測項目
  • 易用性水準（5 分）
    • 定位爲產品是否方便使用，給用戶（尤其是新用戶）的體驗如何。
    • 產品簡單直接，用戶可以基於不依賴過多的指引、介紹即可開始使用，並能很順暢的解決需求——5分
    • 產品設計清晰，用於依賴一定程度上的指引和介紹可以順利地解決需求——4分
    • 產品設計一般，用於在解決需求的過程中可能遇到不少的麻煩，不過也最終可以在有限的時間內解決需求——2-3分
    • 產品設計混亂，用於難以解決需求，也難以瞭解如何去解決需求——0-1分
  • 工程質量水準（10 分）
    • 代碼質量水準（5 分）
      • 定位爲工程代碼本身的質量（即代碼本身的可擴展、可維護性），以及長期維護這一質量的能力。
      • 工程代碼質量優秀，並通過 CI/CD 的形式（即必須在 CI 中運行並能報錯）對代碼質量進行了有效的約束——5分
      • 工程代碼質量優秀，設有代碼規範（需要在倉庫裏有約束腳本或配置文件，並能說明如何運行自動代碼規範測試），但未設置自動化質量約束——4分
      • 工程代碼質量良好，無明確代碼規範，但有較好的可讀性——3分
      • 工程代碼質量尚可，配合有限度的相關人員講解可以做到理解——1-2分
      • 工程代碼質量堪憂，可讀性很低，且相關人員講解依然難以理解或相關人員也搞不清楚——0分
    • 效果質量水準（5 分）
      • 定位爲工程代碼的效果質量（即代碼是否可以正確完成預期內工作），以及長期維護這一質量的能力。
      • 配備了有效、規範的自動化單元測試，且有高覆蓋率（原則上對於不少於 400 行的代碼應不低於 95%，其他代碼不低於 90%）——5分
      • 配備了有效、基本規範的自動化單元測試，且有一定的覆蓋率（原則上對於不少於 400 行的代碼不低於 80%，其他代碼不少於 75%）——4分
      • 配備了相對有效的單元測試，但是規範性或覆蓋率欠佳（例如有單元測試但是覆蓋率明顯不達標）——3分
      • 配備了單元測試，但是測試效果很低，說服力也不足（例如只是象徵性的運行了一下單元測試，幾乎起不到實際測試效果）——1-2分
      • 幾乎未配備單元測試——0分
• 團隊在達成這些目標的過程中的努力程度（15 分）
  • 現場展示質量（5 分）
    • 現場無成員無故缺席，展示內容完整且生動，展示效果優秀，互動相當積極（至少 4 次以上質量不低的提問）——5分
    • 現場無成員無故缺席，展示內容完整充實，展示效果良好，有一定的互動（至少 1 次以上的提問）——4分
    • 現場無成員無故缺席，展示內容完整，展示效果尚可，互動較少或無互動——3分
    • 現場有組員無故缺席，展示內容有明顯的不完整之處，展示效果一般偏蒼白——2分
    • 現場有多名成員無故缺席，展示內容缺漏較大，效果較差——0-1分
  • 團隊成員投入量（10 分）
    • 團隊成員全員付出了大量努力——10分
    • 團隊成員大多付出了大量努力，其他人也做出了應有的貢獻——8-9分
    • 團隊成員大多付出了大量努力，但存在部分人貢獻過低——6-7分
    • 團隊成員整體投入與付出的努力有限——3-5分
    • 團隊成員整體投入甚微，甚至消極怠工——0-2分

老師 1

小組	目標合理性（10）	目標完成度（30）	獎勵分（5）	合計（40）	名次
謎語人隊	8	25	0	33	5
髮際線和我作隊	8	24	0	32	6
美滋滋甜兮兮隊	9	27	2	38	2
萬里陽光號	7	23	0	25.4	7
是兄弟就來摸魚	7	22	0	24.6	8
助教團隊	9	26	0	35	3
刪庫跑路對不隊	9	28	3	40	1
蕩起雙槳	9	24	1	34	4

• 最後一個項目的選題難度最大
• 進取 Key 在創新創業項目中繼續開發
• 題士開源代碼
• 蕩起雙槳相對於 Alpha 階段有顯著改善

小組	Gitlab 使用規範性（5）	團隊協同配合程度（5）	博客互動程度（5）	博客獎勵分（2）	合計（15）	名次
謎語人隊	5	5	4	0	14	1
髮際線和我作隊	4	5	4	0	13	5
美滋滋甜兮兮隊	4	5	5	0	14	1
萬里陽光號	3	4	4	0	11	7
是兄弟就來摸魚	3	4	4	0	11	7
助教團隊	4	5	5	0	14	1
刪庫跑路對不隊	4	5	5	0	14	1
蕩起雙槳	4	5	4	0	13	5

• 總體上互動程度比 Alpha 階段有了加強，主要參考了各個團隊對助教最後的反饋的回覆情況

小組	性能水準（5）	可靠與穩定性水準（5）	安全性水準（5）	易用性水準（5）	代碼質量水準（5）	效果質量水準（5）	合計（30）	名次
謎語人隊	4	4	4	4	5	5	26	3
髮際線和我作隊	3	3	3	4	4	4	21	8
美滋滋甜兮兮隊	5	5	3	5	5	4	27	2
萬里陽光號	5	4	5	3	3	4	24	4
是兄弟就來摸魚	5	5	5	4	3	1	23	5
助教團隊	5	4	5	4	3	2	23	5
刪庫跑路對不隊	5	5	5	5	4	4	28	1
蕩起雙槳	4	3	4	5	3	3	22	7

• 髮際線組採用了第三方的聯機服務，有服務質量上限，無需進行壓力測試，建議該團隊將具體限制說明，但該團隊未進行明確說明
• 摸魚組和助教組在單元測試上基本上沒有說服力，連博客上都沒有截圖
• 蕩起雙槳覆蓋率較低

小組	現場展示（5）	成員投入（10）	合計（15）	名次
謎語人隊	4	9	13	3
髮際線和我作隊	4	9	13	3
美滋滋甜兮兮隊	5	10	15	1
萬里陽光號	3	9	12	7
是兄弟就來摸魚	3	9	12	7
助教團隊	4	9	13	3
刪庫跑路對不隊	5	10	15	1
蕩起雙槳	4	9	13	3

小組	軟件質量（40）	過程質量（15）	工程質量（30）	努力程度（15）	總分（100）	排名
謎語人隊	33	14	26	13	86	3
髮際線和我作隊	32	13	21	13	79	6
美滋滋甜兮兮隊	38	14	27	15	94	2
萬里陽光號	25.4	11	24	12	72.4	7
是兄弟就來摸魚	24.6	11	23	12	70.6	8
助教團隊	35	14	23	13	85	4
刪庫跑路對不隊	40	14	28	15	97	1
蕩起雙槳	34	13	22	13	82	5

老師 2

小組	目標合理性（10）	目標完成度（30）	獎勵分（5）	合計（40）	名次
謎語人隊	7	27	5	28.6	3
髮際線和我作隊	8	28	5	41	1
美滋滋甜兮兮隊	7	27	5	28.6	3
萬里陽光號	6	26	5	26.8	7
是兄弟就來摸魚	6	26	5	26.8	7
助教團隊	7	27	5	28.6	3
刪庫跑路對不隊	7	27	5	28.6	3
蕩起雙槳	8	28	5	41	1

• 依據難度分了 678 三等
• 都很棒

小組	Gitlab 使用規範性（5）	團隊協同配合程度（5）	博客互動程度（5）	博客獎勵分（2）	合計（15）	名次
謎語人隊	4	4	4	2	14	2
髮際線和我作隊	4	4	4	2	14	2
美滋滋甜兮兮隊	4	5	4	2	15	1
萬里陽光號	4	4	4	2	14	2
是兄弟就來摸魚	4	4	4	2	14	2
助教團隊	4	4	4	2	14	2
刪庫跑路對不隊	4	4	4	2	14	2
蕩起雙槳	4	4	4	2	14	2

• 都值得獎勵

小組	性能水準（5）	可靠與穩定性水準（5）	安全性水準（5）	易用性水準（5）	代碼質量水準（5）	效果質量水準（5）	合計（30）	名次
謎語人隊	4	4	5	5	5	5	28	1
髮際線和我作隊	4	4	4	4	5	5	26	8
美滋滋甜兮兮隊	4	4	5	5	5	5	28	1
萬里陽光號	4	4	5	5	5	5	28	1
是兄弟就來摸魚	4	4	5	4	5	5	27	5
助教團隊	4	4	5	5	5	5	28	1
刪庫跑路對不隊	4	4	5	4	5	5	27	5
蕩起雙槳	4	4	5	4	5	5	27	5

• 4 分密碼明文

小組	現場展示（5）	成員投入（10）	合計（15）	名次
謎語人隊	4	7	11	7
髮際線和我作隊	5	9	14	1
美滋滋甜兮兮隊	4	8	12	4
萬里陽光號	4	7	11	7
是兄弟就來摸魚	4	8	12	4
助教團隊	4	9	13	3
刪庫跑路對不隊	4	8	12	4
蕩起雙槳	5	9	14	1

小組	軟件質量（40）	過程質量（15）	工程質量（30）	努力程度（15）	總分（100）	排名
謎語人隊	28.6	14	28	11	81.6	5
髮際線和我作隊	41	14	26	14	95	2
美滋滋甜兮兮隊	28.6	15	28	12	83.6	3
萬里陽光號	26.8	14	28	11	79.8	7
是兄弟就來摸魚	26.8	14	27	12	79.8	7
助教團隊	28.6	14	28	13	83.6	3
刪庫跑路對不隊	28.6	14	27	12	81.6	5
蕩起雙槳	41	14	27	14	96	1

助教 6

小組	目標合理性（10）	目標完成度（30）	獎勵分（5）	合計（40）	名次
謎語人隊	6	22	1	23.6	6
髮際線和我作隊	7	23	0	25.4	5
美滋滋甜兮兮隊	6	22	2	23.6	6
萬里陽光號	8	23	0	31	2
是兄弟就來摸魚	7	25	0	27	4
助教團隊	8	22	0	30	3
刪庫跑路對不隊	9	27	3	39	1
蕩起雙槳	7	17	0	20.6	8

• 謎語人隊要是能部署到pypi官方站的話，拿3分也沒任何問題
• 美滋滋甜兮兮隊確實有長遠貢獻，不過只是一個創業比賽說服力雖有但是也有限
• 刪庫跑路對不隊有明確開源跡象，並且有持續計劃，果斷 3 分

小組	Gitlab 使用規範性（5）	團隊協同配合程度（5）	博客互動程度（5）	博客獎勵分（2）	合計（15）	名次
謎語人隊	5	5	3	0	13	2
髮際線和我作隊	4	4	4	0	12	4
美滋滋甜兮兮隊	4	5	4	0	13	2
萬里陽光號	4	4	4	0	12	4
是兄弟就來摸魚	3	3	5	0	11	6
助教團隊	3	4	4	0	11	6
刪庫跑路對不隊	4	5	5	1	15	1
蕩起雙槳	3	4	4	0	11	6

• 是兄弟就來摸魚、助教團隊、蕩起雙槳所有內容集中在一個倉庫，扣分
• 謎語人隊隔三差五就不回覆博客，但是整體上改進還算到位
• 刪庫跑路對不隊對博客回覆很及時，對深度評審博客有很及時且內容翔實的迴應，肉眼可見的行動力拉滿，額外加一分

小組	性能水準（5）	可靠與穩定性水準（5）	安全性水準（5）	易用性水準（5）	代碼質量水準（5）	效果質量水準（5）	合計（30）	名次
謎語人隊	3	4	5	5	5	5	27	1
髮際線和我作隊	0	4	1	3	2	1	11	8
美滋滋甜兮兮隊	4	5	2	4	3	3	21	4
萬里陽光號	4	4	4	3	3	2	20	5
是兄弟就來摸魚	4	4	5	5	3	1	22	3
助教團隊	4	4	3	4	2	0	17	6
刪庫跑路對不隊	5	5	5	5	3	3	26	2
蕩起雙槳	3	4	4	2	3	1	17	6

• 髮際線和我作隊沒有做壓力測試的跡象
• 髮際線和我作隊明文存密碼，屬於不可容忍級別的的安全問題
• 美滋滋甜兮兮隊有日誌打印密碼的行爲，且服務器用root密碼登錄，安全問題很大
• 助教團隊缺少https，在現行網絡環境下風險較大
• 髮際線和我作隊的遊戲產品手感還是略生澀
• 美滋滋甜兮兮隊產品上的老問題還是存在，但是易用性上有了很大的進步
• 萬里陽光號的圖表軟件還是沒有根本上解決手機端操作困難的困局
• 蕩起雙槳的AI質量肉眼可見的欠佳，解決問題的能力較差
• 這次代碼風格上大多數組普遍缺乏自動化codelint
• 是兄弟就來摸魚隊將代碼風格和單元測試直接放在末尾且允許失敗，這樣的測試根本形同虛設，視爲沒測試
• 這次依然普遍缺乏足夠有效的單元測試，自動化程度也不足
• 美滋滋甜兮兮隊和刪庫跑路對不隊均配備了實質上有效的單元測試，但是均沒有充分落實到CI上
• 萬里陽光號配備了所謂的“關鍵區域”單元測試，但並不是全局單元測試，在思路上存在問題

小組	現場展示（5）	成員投入（10）	合計（15）	名次
謎語人隊	5	9	14	3
髮際線和我作隊	3	8	11	6
美滋滋甜兮兮隊	5	10	15	1
萬里陽光號	3	7	10	8
是兄弟就來摸魚	4	8	12	4
助教團隊	4	8	12	4
刪庫跑路對不隊	5	10	15	1
蕩起雙槳	4	7	11	6

小組	軟件質量（40）	過程質量（15）	工程質量（30）	努力程度（15）	總分（100）	排名
謎語人隊	23.6	13	27	14	77.6	2
髮際線和我作隊	25.4	12	11	11	59.4	8
美滋滋甜兮兮隊	23.6	13	21	15	72.6	4
萬里陽光號	31	12	20	10	73	3
是兄弟就來摸魚	27	11	22	12	72	5
助教團隊	30	11	17	12	70	6
刪庫跑路對不隊	39	15	26	15	95	1
蕩起雙槳	20.6	11	17	11	59.6	7

助教 7

小組	目標合理性（10）	目標完成度（30）	獎勵分（5）	合計（40）	名次
謎語人隊	6	22	0	23.6	6
髮際線和我作隊	8	24	0	32	1
美滋滋甜兮兮隊	6	22	0	23.6	6
萬里陽光號	8	23	0	31	2
是兄弟就來摸魚	7	24	0	26.2	5
助教團隊	8	22	0	30	3
刪庫跑路對不隊	7	27	0	28.6	4
蕩起雙槳	7	18	0	21.4	8

小組	Gitlab 使用規範性（5）	團隊協同配合程度（5）	博客互動程度（5）	博客獎勵分（2）	合計（15）	名次
謎語人隊	5	5	5	0	15	1
髮際線和我作隊	3	4	3	0	10	5
美滋滋甜兮兮隊	5	5	5	0	15	1
萬里陽光號	3	4	5	0	12	4
是兄弟就來摸魚	1	5	4	0	10	5
助教團隊	1	4	4	0	9	8
刪庫跑路對不隊	3	5	5	0	13	3
蕩起雙槳	3	4	3	0	10	5

小組	性能水準（5）	可靠與穩定性水準（5）	安全性水準（5）	易用性水準（5）	代碼質量水準（5）	效果質量水準（5）	合計（30）	名次
謎語人隊	3	4	3	5	5	4	24	3
髮際線和我作隊	0	4	3	4	3	0	14	8
美滋滋甜兮兮隊	4	5	5	5	4	3	26	1
萬里陽光號	3	4	5	2	1	2	17	6
是兄弟就來摸魚	3	4	5	4	2	0	18	5
助教團隊	3	4	3	4	1	1	16	7
刪庫跑路對不隊	3	5	5	5	5	2	25	2
蕩起雙槳	3	4	4	3	3	2	19	4

• 謎語人隊壓力測試不是很完善，而且實測性能沒有超數量級的表現
• 謎語人隊沒有使用https，安全性直接-2，其它隊同理
• 前端未做測試-1，後端未做測試-3

小組	現場展示（5）	成員投入（10）	合計（15）	名次
謎語人隊	5	8	13	3
髮際線和我作隊	5	8	13	3
美滋滋甜兮兮隊	5	9	14	1
萬里陽光號	5	8	13	3
是兄弟就來摸魚	5	8	13	3
助教團隊	5	8	13	3
刪庫跑路對不隊	5	9	14	1
蕩起雙槳	5	8	13	3

小組	軟件質量（40）	過程質量（15）	工程質量（30）	努力程度（15）	總分（100）	排名
謎語人隊	23.6	15	24	13	75.6	3
髮際線和我作隊	32	10	14	13	69	5
美滋滋甜兮兮隊	23.6	15	26	14	78.6	2
萬里陽光號	31	12	17	13	73	4
是兄弟就來摸魚	26.2	10	18	13	67.2	7
助教團隊	30	9	16	13	68	6
刪庫跑路對不隊	28.6	13	25	14	80.6	1
蕩起雙槳	21.4	10	19	13	63.4	8

助教8

小組	目標合理性（10）	目標完成度（30）	獎勵分（5）	合計（40）	名次
謎語人隊	7	21	0	23.8	8
髮際線和我作隊	8	23	0	31	1
美滋滋甜兮兮隊	7	23	0	25.4	6
萬里陽光號	8	23	0	31	1
是兄弟就來摸魚	7	22	0	24.6	7
助教團隊	8	22	0	30	4
刪庫跑路對不隊	8	23	0	31	1
蕩起雙槳	8	21	0	29	5

• 大多數偏保守，部分團隊過於保守

小組	Gitlab 使用規範性（5）	團隊協同配合程度（5）	博客互動程度（5）	博客獎勵分（2）	合計（15）	名次
謎語人隊	4	5	5	0	14	2
髮際線和我作隊	3	4	5	0	12	6
美滋滋甜兮兮隊	5	5	5	0	15	1
萬里陽光號	4	5	5	0	14	2
是兄弟就來摸魚	3	4	5	0	12	6
助教團隊	3	5	4	0	12	6
刪庫跑路對不隊	4	5	5	0	14	2
蕩起雙槳	4	5	4	0	13	5

• milestone個數和issue分配較爲合理纔可以
• issue的交互記錄是否充足
• 團隊合作主要看每日例會的工作分配和展示中的貢獻比，部分團隊的進度不足會扣分
• 博客回覆依據每篇博客回覆情況計算

小組	性能水準（5）	可靠與穩定性水準（5）	安全性水準（5）	易用性水準（5）	代碼質量水準（5）	效果質量水準（5）	合計（30）	名次
謎語人隊	3	4	3	5	5	4	24	3
髮際線和我作隊	0	3	4	4	4	0	15	8
美滋滋甜兮兮隊	4	5	5	4	4	3	25	1
萬里陽光號	4	4	5	3	2	1	19	4
是兄弟就來摸魚	4	3	5	4	2	0	18	5
助教團隊	4	4	4	4	1	1	18	5
刪庫跑路對不隊	4	5	5	4	5	2	25	1
蕩起雙槳	3	3	4	3	3	1	17	7

• 工程質量按照助教 7 的標準來的

小組	現場展示（5）	成員投入（10）	合計（15）	名次
謎語人隊	5	9	14	3
髮際線和我作隊	5	8	13	7
美滋滋甜兮兮隊	5	10	15	1
萬里陽光號	5	9	14	3
是兄弟就來摸魚	5	8	13	7
助教團隊	5	9	14	3
刪庫跑路對不隊	5	10	15	1
蕩起雙槳	5	9	14	3

小組	軟件質量（40）	過程質量（15）	工程質量（30）	努力程度（15）	總分（100）	排名
謎語人隊	23.8	14	24	14	75.8	4
髮際線和我作隊	31	12	15	13	71	7
美滋滋甜兮兮隊	25.4	15	25	15	80.4	2
萬里陽光號	31	14	19	14	78	3
是兄弟就來摸魚	24.6	12	18	13	67.6	8
助教團隊	30	12	18	14	74	5
刪庫跑路對不隊	31	14	25	15	85	1
蕩起雙槳	29	13	17	14	73	6

助教 9

小組	目標合理性（10）	目標完成度（30）	獎勵分（5）	合計（40）	名次
謎語人隊	5	26	0	20.6	8
髮際線和我作隊	6	24	1	25.2	5
美滋滋甜兮兮隊	7	28	2	29.4	2
萬里陽光號	7	25	0	27	3
是兄弟就來摸魚	6	22	0	23.6	6
助教團隊	7	25	0	27	3
刪庫跑路對不隊	8	28	4	36	1
蕩起雙槳	7	20	0	23	7

• milestone 用的很好

小組	Gitlab 使用規範性（5）	團隊協同配合程度（5）	博客互動程度（5）	博客獎勵分（2）	合計（15）	名次
謎語人隊	5	4	5	0	14	2
髮際線和我作隊	4	5	4	0	13	4
美滋滋甜兮兮隊	4	5	5	0	14	2
萬里陽光號	4	4	3	0	11	6
是兄弟就來摸魚	2	3	5	0	10	8
助教團隊	2	5	5	0	12	5
刪庫跑路對不隊	5	5	5	0	15	1
蕩起雙槳	4	4	3	0	11	6

小組	性能水準（5）	可靠與穩定性水準（5）	安全性水準（5）	易用性水準（5）	代碼質量水準（5）	效果質量水準（5）	合計（30）	名次
謎語人隊	2	4	4	4	5	5	24	2
髮際線和我作隊	0	3	3	5	4	4	19	7
美滋滋甜兮兮隊	3	5	3	4	4	4	23	3
萬里陽光號	4	4	5	3	1	5	22	4
是兄弟就來摸魚	4	5	5	4	1	3	22	4
助教團隊	4	4	5	4	2	3	22	4
刪庫跑路對不隊	5	5	5	5	4	4	28	1
蕩起雙槳	3	2	4	5	2	3	19	7

• 蕩起雙槳的測試接口數不多，實測部分接口比較慢
• 謎語人壓力測試過於簡陋
• 蕩起雙槳的服務有些掛了
• 蕩起雙槳的服務有些掛了
• 單詞組明文密碼與打印密碼，password 打印也不符合日誌規範
• 謎語人沒有對 Labels 的說明，扣一分
• 摸魚允許 Fail
• 單詞組的單元測試沒做好
• 單詞實際體驗較差 233

小組	現場展示（5）	成員投入（10）	合計（15）	名次
謎語人隊	3	6	9	6
髮際線和我作隊	4	6	10	4
美滋滋甜兮兮隊	5	8	13	1
萬里陽光號	2	7	9	6
是兄弟就來摸魚	1	6	7	8
助教團隊	4	7	11	3
刪庫跑路對不隊	5	8	13	1
蕩起雙槳	3	7	10	4

小組	軟件質量（40）	過程質量（15）	工程質量（30）	努力程度（15）	總分（100）	排名
謎語人隊	20.6	14	24	9	67.6	5
髮際線和我作隊	25.2	13	19	10	67.2	6
美滋滋甜兮兮隊	29.4	14	23	13	79.4	2
萬里陽光號	27	11	22	9	69	4
是兄弟就來摸魚	23.6	10	22	7	62.6	8
助教團隊	27	12	22	11	72	3
刪庫跑路對不隊	36	15	28	13	92	1
蕩起雙槳	23	11	19	10	63	7

總表

待評審小組	教師 1	教師 2	助教6	助教7	助教8	助教9	最終得分	名次
謎語人隊	86	81.6	77.6	75.6	75.8	67.6	77.367	3
髮際線和我作隊	79	95	59.4	69	71	67.2	73.433	6
美滋滋甜兮兮隊	94	83.6	72.6	78.6	80.4	79.4	81.433	2
萬里陽光號	72.4	79.8	73	73	78	69	74.200	5
是兄弟就來摸魚	70.6	79.8	72	67.2	67.6	62.6	69.967	8
助教團隊	85	83.6	70	68	74	72	75.433	4
刪庫跑路對不隊	97	81.6	95	80.6	85	92	88.533	1
蕩起雙槳	82	96	59.6	63.4	73	63	72.833	7

複審部分前三名依次是：

1. 刪庫跑路對不隊
2. 美滋滋甜兮兮隊
3. 謎語人隊

總體評分

基於上述三項，最終的總體評分爲：

待評審小組	博客	現場評審	複審	總分	排名
謎語人隊	76	45	77.367	198.367	4
髮際線和我作隊	80	40	73.433	193.433	5
美滋滋甜兮兮隊	84	50	81.433	215.433	2
萬里陽光號	77	36	74.2	187.2	6
是兄弟就來摸魚	76	40	69.967	185.967	8
助教團隊	79	44	75.433	198.433	3
刪庫跑路對不隊	84	48	88.533	220.533	1
蕩起雙槳	77	37	72.833	186.833	7

千帆競發圖

現場紀實

在本次答辯中，項目小組、老師、助教、評審團進行了內容豐富的碰撞，本部分將進行一些簡單的紀實。

謎語人隊：

髮際線和我作隊：

美滋滋甜兮兮隊：

萬里陽光號：

是兄弟就來摸魚：

助教團隊：

刪庫跑路對不隊：

蕩起雙槳：

此外，這學期大衆評審團中有幾位同學自己設計了一款用於iOS端的航概APP刷題軟件，並且在學生中進行了一定程度的推廣，取得了不俗的成績也頗有些見解，我們邀請了他們也來講講自己在做這樣一件事情時的心得與理解：

鳴謝與總結

這次我們組織了一次內容相當充實的Beta階段項目展示與答辯，在此我需要向以下人員表達感謝：

• 各項目小組的一整學期的不懈努力，以及對現場展示的辛苦準備
• 兩位老師在課程中的付出，以及組織安排上所付出的努力
• 各位助教在答辯之前的項目評測，答辯中的各司其職，以及答辯後細緻入微的評分（包括幾位無法到場的助教，也都根據現場錄播視頻進行了詳細的評分）
• 7位評審團成員對課程項目的長期關注與體驗，以及站在用戶和技術視角上提出來的一系列實際問題
• 牛雅哲大佬作爲評審團對本次答辯的鼎力支持，對各個團隊工程管理規範鞭辟入裏的指導
• 吳家焱、熊安傑兩位製作iOS端航概APP同學內容充實的項目經驗分享
• 鄒欣老師在beta階段評審方法上提供的關鍵性指點
• 周筠老師對本學期課程的持續關注

總的來說，同學們表現的都各有亮點，但是也暴露出了比較多的問題，其中比較集中的問題有：

• 軟件工程意義上
  • 單元測試沒有用到位
    • 對單元測試的核心思想理解有誤，或不夠重視
    • 單元測試覆蓋率嚴重不足，測試效果不夠
    • 單元測試放在最後去做，而不是去與開發協同前進
  • 代碼風格限制性普遍不夠，大多數組
    • 沒有足夠明確代碼規範
    • 沒有配備基於自動化代碼風格檢查工具的風格檢查
  • 沒有充分使用CI/CD
    • 單元測試大多數組都沒有在CI/CD上自動化，即便自動化了的組也大多沒有在CI/CD上做到足夠有效的自動化（allow_failure、低覆蓋率、該忽略的不忽略等）
    • 代碼風格測試大多數組沒有做到CI/CD上自動化，即便自動化了的組也基本上沒有做到有效約束（基本上都是直接忽略測試結果）
    • 自動化部署大多數組沒有做到CI/CD上自動化，實現了的組也多少都存在一定的不規範操作
  • 對Issue的理解與使用有較大問題
    • Issue的意義不只是列出一項工作，而是應該在上面進行任務的持續追蹤，和必要的討論，一個Issue應該足以反映一個任務的前世今生，讓組內人員任何時候翻到都能瞭解其完整生命週期
    • 然而大部分組Issue基本上就是當做一個task，然後完事了close了事，其中沒有任何過程
    • 筆者之前在各小組博客裏面輪番轟炸了數波之後，大部分小組開始學會在Issue中關聯代碼、Merge Request和成果展示，但是依然很少有必要的討論，還是更喜歡用微信羣討論，更喜歡在熟悉但是低效的泥潭裏打滾
  • 對Merge Request的理解與使用有較大問題
    • Merge Request的意義在於代碼從開發者分支（或者fork倉庫）進入主分支（或者上級分支）的過程，注意這是一個過程，其中也應該包含這次代碼提交的前因後果，以及必要的審覈、修正與討論
    • 然而一部分組完全沒有用上Merge Request這一機制
    • 對於用上了的組，也常常在把Merge Request單純的當做代碼提交，一路通過，毫無內容的記錄，甚至看都不看（一個Merge Request用到底、盲目merge等）
• 軟件產品意義上
  • 很多小組還是明顯的表現出“唯技術”的思維，認爲一切事項都該給開發讓路，在其他同樣重要但沒那麼熟悉的事情（例如實打實的需求分析、產品的非技術層面設計與宣傳推廣等）上卻不肯下足功夫，或者只肯下作業意義上的功夫且大多流於表面。殊不知方向錯了，再努力也只會在不歸路上一路疾馳直至毀滅
  • 不少小組在推廣的時候還是侷限於手邊的人和圈子。在這個問題上，可以引用一個故事

從前有個人，晚上回家，看到一個人在路燈下找東西。詢問之下，原來對方是在找鑰匙，遂幫助他一起找。
找了半天，仍然沒有找到，又問：“你是在哪裏丟的？”
“大約就在這一塊。”對方比劃了很大一個區域，答道。
“那爲什麼不去那裏找呢？”這個人指向對方比劃區域內的另一塊地方。
“因爲那裏沒有燈光。”對方回答道。

道理基本上就是這樣——真正的目標用戶不去挖掘，也不肯去好好接觸，美其名曰不好弄，實際上可不就是和上面只肯在亮光下找鑰匙一個思路麼？況且就算沒光，難道自己就不可以帶一根手電筒，然後去該找的地方好好找找，活人就該被尿憋死？歸根結底，還是在心理上重視與否，而這也是對課程組而言最難的地方。破山中賊易，破心中賊難，這些事情不僅對於未來的項目團隊來說應當警醒，對課程組來說也是務必引起重視的。私以爲，這其中最需要的還是各方的戒驕戒躁，少些主觀臆斷的沉溺，多些心思踏實的踐行，纔是正道。

以上就是對beta階段的一些總結，感謝各位的付出。實際上筆者無論是作爲個人，還是作爲今年的敏捷軟工助教頭子，都還是有不少話想說的。以及今年的改革不管怎麼說，也還是在不少事情上有過探索也邁出了步子的。這些筆者打算後續專門用一篇博客做總結與介紹，敬請期待。