以《構建之法》為核心的軟體工程課已經在全國幾十個學校開展了好幾年，由於採用 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） 每個團隊寫乙個alpha/beta 階段的總結展示部落格 （不要寫 ppt），具體要求請看老師的說明。
2） 每個複審人看所有團隊的總結展示部落格，以及**質量，實際測試結果， 決定名次（沒有並列），說明專案的優點和缺點分析（不少於 140 字）
誰來做複審人：老師，助教，每個團隊選乙個本團隊的代表
團隊部落格列出團隊的排名，和對這些團隊的點評（不包括本團隊）
複審人看什麼：
- 基本要求：團隊成員都到場了麼（不倒扣分），現場講解、回答問題水平如何？
- 軟體的質量：解決原計畫解決的問題了麼，軟體執行質量如何？使用者有多少，使用者反饋如何？
- 軟體工程的質量：**在**？ **能在新的機器上構建成功麼？ **可維護性如何？每日構建有麼？
專案如何管理的？燃盡圖反映真實狀態麼？老師和助教的點評有回答或改進麼？
複審怎麼做：
a) 面對面集中做，老師和所有在場的複審人現場提問，排名次
軟體 = 程式 + 軟體工程
軟體（的質量） = 程式（的質量）+ 軟體工程（的質量）
我們要好好測試一下程式的質量，給出明確的，定量的評定。同時我們要觀察這個小組軟體工程的質量（通過他們的每日例會，燃盡圖，以及其它部落格）點評他們專案的目標實現了麼？專案的風險是如何應對的？找到使用者的痛點並解決了麼？ 對主要和次要的需求是如何取捨的？如果換成我來領導這個小組，我會做什麼不一樣的事情？
小組的名字和鏈結
優點
缺點，bug 報告（至少140字）
最終名次
（無並列）
team 1
...程式有什麼具體的bug？
專案的目標實現了麼？專案的風險是如何應對的？找到使用者的痛點並解決了麼？
對主要和次要的需求是如何取捨的？
源**管理如何？
如果換成我來領導這個小組，我會做什麼不一樣的事情？
team 2
......
3） 助教收集所有複審人的名次資訊， 按平均名次排列， 並給予分數。
4） 這個展示作業的滿分是 100 分，其餘名次按照階梯遞減（例如，每個階梯是 10 分或 5 分），取決有多少團隊參加了評比，階梯要拉開，也要保證付出了努力的團隊獲得相當於及格的分數。 也可以分類評比，例如，所有自選專案在一類，所有做學校老師布置的專案在一類，等。
軟體結課 軟體工程課的評價
這門課程總體上說起來就是一門理論課程，就和一些文科課程是一樣的。但是老師在課堂上的講解卻很生動詳盡，每堂課只要你去聽，也會學到很多。最關鍵的是老師讓我們理論結合實際，自己去實踐，去親身體會，這比單純的講解要有效的多了。而在團隊開發過程中，我們也學到了很多，結對開發，andriod，測試，等等一系列的...
對於軟體工程課的認知和目標
下學期我們會上一門課 軟體工程，寒假對它進行了簡單的了解。下面是我對自己下學期的期望和努力目標1 我希望自己上課用心聽下課也多花費時間去練。寒假我聽了一門課叫learning how to learn，老師說這種抽象的非語言類的學科就要多練才能更靈活更長久的掌握。2 希望自己上課時反應快一點再快一點...
本學期軟體工程課的感受
王老師您好 很榮幸這半學期能夠修上您的這一門軟體工程課，都說軟體工程系有乙個大牛的系主任，上了你的課之後才真實的覺得，原來這些話不是吹的，您的教學理念就很獨特，也很前言，讓同學們真實的感受到了軟體開發的過程，沒有上這門課之前，對於軟體開發沒有什麼概念，更別說團隊開發了，現在看來以前的團隊專案都不叫團...