考考考，老師的法寶；分分分，學生的命根。?以《構建之法》為核心的軟件工程課已經在全國幾十個學校開展了好幾年，由于采用 Learning by doing (做中學) 的方法， 同學們通過實際的作業獲得分數，逐漸累積并轉換為最終分數，而不是等到期末的考試得到一個分數。 這種方式有很多好處，但是也引起一些困惑，每次開課的后期，大家都會對分數系統有一些疑問。 這里講一些分數系統的設計理念，和如何對付一些新問題 (有很多同學根本不做作業怎么辦， 同學開始浪蕩，最后想及格怎么辦， 異常差的學生導致分數系統的映射有偏移怎么辦...) 。 這個博客就是想解答這些問題。

分數系統設計的理念：

- 每次發表的作業都有分數，在學期的任何時候，都可以根據公式，從已有的分數中推算出所有學生的期末成績 (這樣學生就不會說：啊老師！我從來不知道我有不及格的風險啊...)

- 獎勤罰懶，分數要拉開優秀作業和一般作業的差距，遲交 0 分，過期不交作業，倒扣分。

- 鼓勵交流。作業不是一次交了就完事，再也不看， 而是學生和老師的一個交流途徑。 老師和助教給學生博客的評論，學生應該積極回應。 回應就有分數，不回應就會被扣分。?

? 師生要互相質疑，問答，就像培根說的：

? ? ? ? 真理之川從它的錯誤之溝渠中流過；像萌芽一般，在一個真理之下又生一個疑問，真理疑問互為滋養。

- 分數規則對所有人開放，盡量保持簡明。 用Excel 表就和一些簡單公式可以統計好。- 允許學生花額外的努力獲得更多分數。- 最后的分數是個人努力和全班同學相對排名的體現， 但是少數學生的異常情況 (分數特別高、特別底)不會對其他同學的分數產生大的影響。?

這個分數系統是建立在：“全班同學都至少付出了一定程度的努力” 的假設上的。如果少數同學什么作業都不做，那么這個分數系統不是為這樣的學生設計的，這些同學不必參加后面提到的映射等操作。??

《構建之法》里的分數設計中的概念和詞匯定義：

學生要做項目(個人項目，結對項目，團隊項目)，項目有作業， 作業分代碼作業和博客作業。 每個作業都會打分，基本上每個作業滿分都是 10 分，最低分是 (-10) 分。? ?學生在團隊項目中要做兩次階段性的展示(alpha 發布 和 beta 發布)，這兩次發布非常重要，體現了一個團隊一段時間的努力成果。團隊通常是寫一個博客，把展示內容都組織成為一個博客，同時團隊可以現場展示他們的成果。這個作業的滿分是 100 分。 ?

分數轉換的流程是：?

? ? 原始分數 --> 累積并映射到各自區間 --> 歸一化為百分制 --> 加上可選的個人附加分 --> 老師的調整 -->成績單上的分數?

原始分數的累積和區間映射

原始總分=? ? ?? 個人項目成績 ? ? ? ? ?? (20%)? + 結對項目成績 ? ? ? ? ?? (20%)?? + 團隊項目Alpha成績 ?? (25%)? + Alpha階段個人貢獻分? (5%)? + 團隊項目Beta成績 ? ?? (25%)? + Beta階段個人貢獻分 ? (5%)

個人項目成績 (占原始總分的 20%) =

? ? ? ? ? ? ? 每次作業成績的累加，再把全班同學的最高成績映射 20分，這個最高的累加分數到 20 分的比例為 R, 其他同學的成績按 R 做映射。????????????? 作業成績累計是負分的同學，映射為 0 分。

? ? ? ? ? ? ? 例如：三個同學 A, B, C 在個人項目中分別得了 50， 30， 10 的原始分， 這個項目的滿分是20 分。 最高的原始分50 要映射到 滿分20 ， 比例是 50 / 20 = 2.5， 所以 ?R = 2.5

? ? ? ? ? ? ? 這樣我們就可以用 比例R 推出， B 得分=30 / 2.5 = 12， C得分 10 / 2.5 = 4

結對項目成績 (占原始總分的 20%)= 每次作業成績的累加，再把全班同學的最高成績映射 20 分，這個最高的累加分數到 20 分的比例為 R, 其他同學的成績按 R 做映射。????????????? 作業成績累計是負分的同學，映射為 0 分。

團隊項目成績 = 每次作業成績的累加，再把所有項目組的最高成績映射為 25 分, 其他小組根據映射比例做同樣的映射。????????????? alpha, beta 兩次團隊項目同樣處理，各占 25%?

個人貢獻分 = 和個人項目成績類似，最高分映射到 5 分，其余按比例映射。????????????? alpha, beta 項目同樣處理

為什么要區間化？因為團隊項目在進行過程中會有很多次作業(項目啟動，需求，設計，WBS, 每日例會報告， 展現博客， 測試，復審得分...) 這個原始分會遠遠超過個人項目的原始分，這兩種分數必須分別歸類到各自的區間中，以保證各種努力在最終分數有適當的比例。

歸一化

得到原始總分之后，原始總分要做一個歸一化處理，回歸到百分制。 原始分最高的獲得100 分，其他人按照 ?最高原始分/100 的比率做相應的映射。這個方法和個人項目原始分映射類似。?

注：既然映射的參數是受到最高分的同學影響， 那么班級里有一個非常優秀的學生，他的原始分特別高，會導致其他學生的分數被映射得比較低，這公平么？ 我們用軟件業的瀏覽器市場做例子，原來的瀏覽器IE 是成績比較好，但是后來班里面來了Chrome，Firefox 等學生，原始分最高的同學，映射到了100 分，遺憾的是，IE 不是最優秀的同學，那么IE 的最終分數就降低了，這有道理吧？ IE 要獲得高分，應該自己努力，而不是埋怨別的同學作業做得更好，對吧？

原來采用的是高限和底限都有的映射， 例如原始分分布是 [20 .. 90]， 要映射為 [50.. 100], 這個兩端都要照顧到的映射方式有一個巨大的缺點 -- 如果班級里面有一個較差的學生，那么其他人的分數就要被映射得比較高。 ?那么，為何一個同學的最終分數會受到班里面最差的同學的影響呢？ ?在軟件市場上，最爛的軟件不會影響優秀軟件的市場占有率，對吧？ 因此，在實驗了幾年之后，最低端的映射就不考慮了。?

那么，一些同學原始分低怎么辦？ 整體分數的分布比較奇怪怎么辦？請繼續看。

通過附加項目做最后調整

最后，每個同學有機會做額外的附加項目 (動機可能是：提高自己水平，獲得更高分數， 避免不及格，等等)， 個人附加項目分數的最高分是 10 分， 這樣，如果有本科生同學的原始總分是全班最低的，映射為 50 分，那么，他可以通過掙這個附加項目分數的滿分 10 分來避免不及格的命運。

附加項目做什么呢？例如，幫助老師做一些教學輔助工作，再做一個有難度個人項目，寫深入的讀書/論文筆記，等等。在學期過程中，和老師/助教有深入交流的學生(例如看博客的問答)也可以獲得一些附加分數，這個由助教掌握。?

一些老師出于種種原因，還想加一個筆試環節。那么，筆試可以作為這個課程的附加分數，筆試的最高分映射為10分，當然，根據學校的要求和具體情況，筆試的最終分數也可以提高。?

分數分布奇怪怎么辦

在少數情況下，一個班的分數會出現奇怪的分布，例如，有一兩個特別優秀的學生，他們得到非常高的分數，會導致其他同學的相對分數太低；或者學校對分數段的人數有規定，或者領導要求把某個不及格的分數變成及格(我聽說過兩次這樣的情況)。

　　把過于離散的分數分布變換到比較集中，靠近100 分： ?把所有的分數都開平方，再乘以 10. ?這個過程讓所有非零的分數向 100 分靠近。

　　把過于集中的分數分布變換到比較離散，遠離100 分： ?把所有的分數都和自己平方，再除以 10. ?此過程讓所有小于 100 的分數向 0 分靠近。

團隊項目的展示評審階段如何打分

為什么要研究各種打分方法，制定詳細的規則？因為要解決實際問題，我們在實踐中碰到什么問題呢？

問題1：同學們的團隊項目往往拍腦袋就想出來，并沒有很嚴肅地做各種軟件工程的調查。中途拍大腿后悔， 最后拍屁股走人，項目爛尾。 ?問題2：每個軟件項目都可能是很好的軟件工程案例， 但同學們對于其他團隊的項目不太關心， 只是最后評審的時候看看別人軟件的界面，草草給一個分數，浪費了很多的學習機會。??

解決：把點評做成有趣的場景， 讓同學們專注于分析各個項目的成功的可能性， 讓同學們自己用批判的眼光分析問題，跟蹤項目的進展。?

?具體方法：

讓所有團隊根據? NABCD 自己審核一下自己的團隊項目，把 NABCD 元素加到自己的團隊博客的項目說明中， 同時說明預期的 “項目發布后3天的用戶量”。? 可以給機會讓同學們修改團隊項目，所有團隊發表博客。

然后， 所有團隊寫一個博客， 依次評價其他團隊的項目立項 NABCD， 排名次 (名次沒有并列)。? 助教統計所有名次，? 名次最低的團隊必須做出重大修改， 包括選一個新的項目。

可以用風險投資做比喻 ，? 每個學生都是有錢的風投資本家，? 要給這個班級的所有項目投資， 10 個團隊項目你只能投6 個，? 你投哪些？?? 請列出你的選擇。 ?有些同學們不是很想創業，做有意思的項目吸引風投嗎？? 這就讓他們練習實際的風投。? 例如， 同學可以對任意項目投資， 每個項目可以投 一元錢。? ? 評審獲得前三名的項目對應團隊的同學就能得到當初投資的錢。? 如果這個項目在學期最后沒有進入前 3 名， 這個錢就歸老師分配。? 老師拿了這些錢做獎品， 例如：再分給那些投資了前三名團隊的學生。

評審階段的打分安排：

1) 每個團隊寫一個alpha/beta 階段的總結展示博客 (不要寫 PPT)，具體要求請看老師的說明。有些項目暫時還沒有實際用戶，或者面臨各種問題， 那團隊可以深入分析失敗的原因，并總結“我學到了什么軟件工程的原理，獲得了什么經驗教訓”，這也達到了學習的目的。?

2) 每個復審人看所有團隊的總結展示博客，以及代碼質量，實際測試結果， 決定名次(沒有并列)，說明項目的優點和缺點分析(見下表)

? ? ? 誰來做復審人：老師，助教，每個團隊選一個本團隊的代表

? ? ? ? ? ? ? ? ? ? ? ? ? 團隊博客列出團隊的排名，和對這些團隊的點評(不包括本團隊)

? ? ? 復審人看什么：

? ? ? ? ? ? -?基本要求：團隊成員都到場了么(無理由不到的，要倒扣分)，現場講解、回答問題水平如何？ 是否各個角色都有發言和回答問題的機會？

? ? ? ? ? ? - 軟件的質量：解決原計劃解決的問題了么，軟件運行質量如何？用戶有多少，用戶反饋如何？

? ? ? ? ? ? - 軟件工程的質量：代碼在哪里？ 代碼能在新的機器上構建成功么？ 軟件的架構如何 (下表有更詳細的說明)？代碼可維護性如何？每日構建有么？

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? 項目如何管理的？燃盡圖反映真實狀態么？老師和助教的點評有回答或改進么？

? ? ? 復審怎么做：

? ? ? a) 面對面集中做，老師和所有在場的復審人現場提問，排名次

? ? ? b) 不能面對面的，通過看博客和代碼，博客評論交流的方式平均并排名次。 大家都是學過軟件工程，做過項目的人了，評論要有點專業性，不能光談感性認識 (“這個小組做的App 看起來還可以...”), 而是要點評這個產品和軟件工程相關的地方，書上提到下面的公式：?

軟件 = 程序 + 軟件工程

軟件_(的質量) = 程序_(的質量)+ 軟件工程_(的質量)

我們要好好測試一下程序的質量，給出明確的，定量的評定。同時我們要觀察這個小組軟件工程的質量(通過他們的每日例會，燃盡圖，以及其它博客)點評他們項目的目標實現了么？項目的風險是如何應對的？找到用戶的痛點并解決了么？ 對主要和次要的需求是如何取舍的？如果換成我來領導這個小組，我會做什么不一樣的事情？

有不少團隊的項目看似功能都有，但是一具體使用就出現很多問題；當然還有不少團隊項目具體功能不行， 但是項目成員號稱：“我們的架構好！”， 一個軟件的功能性特質比較好評判，那么那些 “非功能性” 的特質，如何評判呢？我們看看如下幾個方面，它們也有各自的? “非功能性測試” (參見《構建之法》相關章節)：

高性能

從測試的角度看：系統最快能有多塊？支持最多的用戶，能有多少？換句話說，系統必須滿足預期的性能目標，在并發用戶數(Concurrent Users)、并發事務數(Transactions per Second，TPS)、吞吐量(Throughout)等指標方面達到預估值，支撐使用人群的正常使用操作。團隊項目考察：團隊有測試數據或真實運行數據說明軟件達到了哪些高性能指標？

可靠性 & 穩定性 & 可用性

很多軟件是客戶業務系統一部分，它直接影響到用戶的經營和管理，客戶希望軟件在使用周期內長期穩定運行，這要求系統具有一定的容錯能力。可用性是指系統在指定時間內的提供服務能力的概率值。我們一般采取集群、分布式等手段提升系統的可用性。我們不能認為所有軟件都像一些消費類型的手機App那樣 - 閃退多，重啟一下就好。 團隊項目考察：團隊是否有壓力測試，是否收集程序崩潰、閃退記錄？MTTF?是多少？

安全性

用戶的業務數據是具有非常高的商業價值，如果被泄露或篡改將會帶來重大損失。安全性是軟件系統的一個重要的指標，也是架構設計的一個重要目標。團隊項目考察：軟件是怎么保護用戶隱私的？軟件能防止外力入侵系統么？

靈活性 & 可擴展性

軟件系統應該具備滿足不同特點的用戶群和目標市場的能力，更靈活。業務和技術都在不斷的發展變化，軟件系統需要隨時根據變化擴展改造的能力。一個簡單的例子：用戶想把App 的界面都換成另外一種語言，軟件如何做到？是要重啟App，還是要下載一個不同的App？ 一個稍微復雜的例子：一個團隊號稱做了 A大學校園周邊的 “美食指南”App，如果讓這個軟件也支持另一個城市的 B大學的周邊美食， 程序要全部重新寫呢，還是只需簡單換一些數據、配置信息就可以？我們軟件工程經常講的高內聚，低耦合就發揮作用了！團隊項目考察：看源代碼，分析它的模塊化、內聚、耦合、可擴展性。

易用性

軟件系統必須擁有較好的用戶體驗，便于用戶使用。團隊項目考察：請按照《構建之法》第十二章 “用戶體驗”的建議來測試易用性。

可維護性

軟件系統的維護包括修復現有的錯誤，以及將新的需求和改進添加到已有系統。因此一個易于維護的系統對于用戶提出的問題或改進，可以及時的實現高效的反饋和響應支持，同時有效降低維護成本。團隊考察：代碼注釋、文檔，代碼質量。問自己：你愿意接受這樣質量的源代碼么？

經常有人說：“架構是系統非功能性需求的解決辦法的集合”，如果同學們自稱“架構好”，那就用數據來證明。

小組的名字和鏈接	優點 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?	缺點，bug 報告(至少140字)	最終名次 (無并列)
team 1	?...	程序有什么具體的bug？ 項目的目標實現了么？項目的風險是如何應對的？找到用戶的痛點并解決了么？ 對主要和次要的需求是如何取舍的？ 源代碼管理如何？ “非功能性質量”如何? 選擇至少 3 個方面來測評 如果換成我來領導這個小組，我會做什么不一樣的事情？	?
team 2	?...	?...	?

3) 助教收集所有復審人的名次信息， 按平均名次排列， 并給予分數(再次強調：小組互相評名次，不打分，助教最后打分)。

4) 這個展示作業的滿分是 100 分，其余名次按照階梯遞減(例如，每個階梯是 10 分或 5 分)，取決有多少團隊參加了評比，階梯要拉開，也要保證付出了努力的團隊獲得相當于及格的分數。 也可以分類評比，例如，所有自選項目在一類，所有做學校老師布置的項目在一類，所有 “微信小程序”類型在一類，等。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的软件工程课的分数系统，和打分方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。