軟件工程課的分數系統，和打分方法

時間 2019-11-06

標籤軟件工程分數系統打分方法简体版

原文原文鏈接

考考考，老師的法寶；分分分，學生的命根。

以《構建之法》爲核心的軟件工程課已經在全國幾十個學校開展了好幾年，因爲採用 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	...	...