考考考，老師的法寶；分分分，學生的命根。
以《構建之法》為核心的軟件工程課已經在全國幾十個學校開展了好幾年，由於采用 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 分），取決有多少團隊參加了評比，階梯要拉開，也要保證付出了努力的團隊獲得相當於及格的分數。 也可以分類評比，例如，所有自選項目在一類，所有做學校老師布置的項目在一類，所有 “微信小程序”類型在一類，等。