提要——本學期評分概述
評分概覽



2020春W班評分展示,千帆競發圖、工程能力變化圖、工程能力雷達圖、歷次作業成績、學號搜索成績等:https://www.hengyumo.cn/score-show/
助教總結
1. 目錄/班級鏈接
班級鏈接:2020春|W班 (福州大學)
總結目錄
2. 學期工作總結
2.1 學期工作的點評數據視圖

點評數量變化分析
- 第8周和第14周沒有新的作業,所以點評較少
- 點評數量從開學開始趨勢較平穩,到中期有一個遞減,這是當時第一次團隊作業發布,只需要每個團隊交一篇博客,因此點評的工作量減小了。當然文檔評審和答辯的工作也相應增加了。
- 到了團隊沖刺時達到頂峰,這是因為當時團隊沖刺,每個團隊每天都發日志,本着周老師“堅持點評、及時反饋“的原則,當時一整個星期都堅持每天看完團隊的日志博客。
到中后期,這時團隊沖刺告一段落,點評數量減少。 - 到學期末,最后一次個人總結作業,為了深刻的了解同學們的真實反饋,把這次作業幾乎每篇都看了一遍,因此點評數量增多。
點評數據總覽



點評分析
- 團隊類型作業約占2/3左右,這是因為團隊作業持續時間最久,從第4周一直到第18周,也是課程的重點;
- 本學期的點評數量相比上學期仍有增加,達到了449。盡管四月份和五月份十分的忙碌。
2.3 學期工作時間分布
平均每周花在助教的點評和評分工作上的時間約6-10小時;
開發自動評測、評分展示系統、以及各種腳本工具、助教協作系統等,花去了兩個多月的時間,累計耗時300小時+,累計編碼4萬-5萬行。
2.3 工作各項參數
- 設計和發布作業:5次
- 參與評分:12次
- 參與答辯:7次
- 直播技術分享:3次
- 程序評測與評分:5次
3. 自動化工作
Linkin雲評測系統:
初衷:
- 大四學期擔任軟件工程實踐助教
- 作業多、評分工作量大、復雜
- 既然是軟件工程課那就嘗試用軟件工程解決
- 開發一個評分、評測、可視化分析展示的平台
意義:
- 提高程序實踐類課程的評分效率
- 方便學生看到自己實時的得分,從而知道自己的學習情況
- 對微服務架構進行系統化的嘗試
特色&難點
- 采用微服務架構,服務獨立部署,易於擴展
- 采用從GitHub下載倉庫的方式,相比OJ,支持對更復雜的項目進行測試
- 自動生成微服務系統的資源、字典
- 流量監控和爬蟲防護措施
- 助教在線協作評分
- 集群監控、熔斷監測
- 對評分進行多個維度的分析與展示
- 權限設計、安全加密完善,系統安全性高
核心技術
- Spring Cloud Zuul 搭建服務網關
- Spring Cloud Eureka 實現服務注冊中心和服務發現
- Spring Cloud Feign、Ribbon實現服務通信和負載均衡
- Spring Cloud Hystry、Dashboard實現服務熔斷和服務監控
- 大量使用緩存(Redis、Ehcache)、消息隊列(Rabbit MQ)
架構


系統圖片
服務注冊中心:

熔斷監測與集群監控:

后台主界面:

多級權限:管理員/教師/助教



助教評分與協作:

評分可視化分析展示:


程序評測:


4. 工作改進
4.1 自我改進
- 作業規范化加強了
- 作業創新性加強了(疫情系列作業)
- 點評提高:發現問題、體現針對性
- 加強了評分約束
- 極大加強了自動化工具
- 首創直播,分享技術
4.2 承前啟后
- 繼續延續每周小結,同時制定的周小結模板得到周老師的推薦使用
- 繼續采用自動評測評測程序,提高工作效率
- 專注每一次(線上)答辯過程
- 挖掘優秀的助教苗子,為后續課程獻力
- 專注每周的點評,持之以恆
5. 工作反思
5.1 工作不足之處
對助教團隊的管理缺乏具體的手段,應該更加強調助教的任務指標。但是這需要提前建立一個助教的考評機制,由老師來牽頭,類似於公司績效制度。
5.2 與同學們的交流
我相比同學們,只大他們一屆;痴長一年,技術上比他們多看幾本書,因此他們的問題也多半能解答一下;
IT行業是典型的工程師思維,大家普遍會尊重技術更牛的人,因此加強自身的技術水平很重要;
此外發布通知時盡量減少命令式的語氣,多用溫和的語氣;這一點能在同學們心中留下好一些的印象;
5.3 學期工作計划
助教工作方面跟着課程的進度走,會提前計划下周要做的事情;
學期計划以開發完成各項自動化工具為前提,輔助提高課程質量;
5.4 作業點評
這學期的作業基本做到了消滅零評論,這主要得益於團隊的精誠合作,雖然這學期大家都遇到了很多的事,但是大家仍然能互相包容互相支持,這是最讓人感動的❤;
但在“及時評論”方面還有一些不足,因為作業提交普遍集中到作業截止的原因,導致作業截止當天的作業量很大,沒有辦法當天全部點評完;
5.5 助教合作
本學期的助教合作還是比較默契的,無論是點評工作還是評分工作上。這學期和徐助教、林助教、陳助教都配合的很愉快,他們都十分的優秀。😁
6. 啟發和建議
6.1 問卷調查





6.2 建議
1. 評審表應該統一由助教設計,並單獨給每個組填寫
去年這學期時項目評審表是小組自行設計的,打印出來分發給老師同學填寫,這一方式的數據收集難度較大,需要將紙質數據轉為excel;此外讓小組自行設計評審表,也會導致各組評分項分值設置不同的情況(比如某個小組PPT做的好,就把自己的PPT分數占比設高);
這學期助教工作做的改進就是采用共享文檔來統一收集,這一方式使得數據的搜集更為容易,也統一了評分的標准,但是評分變成公開,影響了收集到的評分的准確性,導致評分有一定的趨同性;
在下學期應該做相應的改進,給每個小組提供一份在線評分表,用來為其他的所有組統一評分;
2. 應該繼續加強各類技術教程,提前安排同學們學習
普遍欠缺的教程是web開發、代碼規范、github使用、IDE使用這些方面;
3. 團隊GitHub實訓的題目應該提前一到兩天通知
本學期的團隊編程時間相對而言太過於倉促了。
4. 組隊方式
可以嘗試采取之前我在周小結中提到的自由組隊+隨機抽取的機制。自由組隊+隨機抽取的方式:每個隊先招募5個人,剩下的2人隨機分配,避免弱弱結合,比如這學期,我們班級一共13個隊,每個隊先招5人,扣去65人,剩下的(92-65)人隨機的平均分配到各個隊伍,如果人數有剩余,沒法保證隊伍人數一致,就用抽簽的方式保證公平,通過這種方式減少技術實力對團隊項目進行的影響。
5. 換組繼續保持,但是要繼續細分技術保證換組的正向作用
采取主動協調換組+被動隨機換組的方式來進行這學期的換組工作。其中主動協調換組是讓各小組有意向換組的同學先進行報名(每組最多一人),被動隨機換組是采取隨機方式,在沒有換組的組之間,根據組同技術分類+個人同技術分類的方式,來進行換組。因此在進行換組之前采取共享文檔的方式收集了班級同學的組技術分類和個人技術分類。通過這種方式可以減少換組之后的適應成本,模擬實際人員調動情況,減少同學們的抗拒。
6. 補交作業的問題
因為博客園提交作業后還能做對應的修改,這導致有部分同學鑽空子,先在截止前交作業,然后再慢慢修改;
這方面只能希望博客園能做相應的完善;因為助教沒有辦法在短期內為所有作業打完分;
7. 繼續在自動化工具這條路走下去
爭取最大程度的解放助教/老師的那些繁重的工作,這樣就可以專注於課程的優化和提高了。
7. the end
最后,感謝一直勉勵我的汪老師、傅老師、周老師!感謝一起努力一起共事的其它三位助教!!
感謝鄒欣老師周筠老師背后的構建之法團隊!!!
期望福大后續軟件工程實踐會越來越好!!!
致敬我的母校和培養我成長的軟件學院😘,期望越來越好~
