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

分?jǐn)?shù)系統(tǒng)設(shè)計的理念：

- 每次發(fā)表的作業(yè)都有分?jǐn)?shù)，在學(xué)期的任何時候，都可以根據(jù)公式，從已有的分?jǐn)?shù)中推算出所有學(xué)生的期末成績 (這樣學(xué)生就不會說：啊老師！我從來不知道我有不及格的風(fēng)險啊...)

- 獎勤罰懶，分?jǐn)?shù)要拉開優(yōu)秀作業(yè)和一般作業(yè)的差距，遲交 0 分，過期不交作業(yè)，倒扣分。

- 鼓勵交流。作業(yè)不是一次交了就完事，再也不看， 而是學(xué)生和老師的一個交流途徑。 老師和助教給學(xué)生博客的評論，學(xué)生應(yīng)該積極回應(yīng)。 回應(yīng)就有分?jǐn)?shù)，不回應(yīng)就會被扣分。?

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

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

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

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

《構(gòu)建之法》里的分?jǐn)?shù)設(shè)計中的概念和詞匯定義：

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

分?jǐn)?shù)轉(zhuǎn)換的流程是：?

? ? 原始分?jǐn)?shù) --> 累積并映射到各自區(qū)間 --> 歸一化為百分制 --> 加上可選的個人附加分 --> 老師的調(diào)整 -->成績單上的分?jǐn)?shù)?

原始分?jǐn)?shù)的累積和區(qū)間映射

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

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

? ? ? ? ? ? ? 每次作業(yè)成績的累加，再把全班同學(xué)的最高成績映射 20分，這個最高的累加分?jǐn)?shù)到 20 分的比例為 R, 其他同學(xué)的成績按 R 做映射。????????????? 作業(yè)成績累計是負(fù)分的同學(xué)，映射為 0 分。

? ? ? ? ? ? ? 例如：三個同學(xué) 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

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

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

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

為什么要區(qū)間化？因為團(tuán)隊項目在進(jìn)行過程中會有很多次作業(yè)(項目啟動，需求，設(shè)計，WBS, 每日例會報告， 展現(xiàn)博客， 測試，復(fù)審得分...) 這個原始分會遠(yuǎn)遠(yuǎn)超過個人項目的原始分，這兩種分?jǐn)?shù)必須分別歸類到各自的區(qū)間中，以保證各種努力在最終分?jǐn)?shù)有適當(dāng)?shù)谋壤?/p>

歸一化

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

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

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

那么，一些同學(xué)原始分低怎么辦？ 整體分?jǐn)?shù)的分布比較奇怪怎么辦？請繼續(xù)看。

通過附加項目做最后調(diào)整

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

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

一些老師出于種種原因，還想加一個筆試環(huán)節(jié)。那么，筆試可以作為這個課程的附加分?jǐn)?shù)，筆試的最高分映射為10分，當(dāng)然，根據(jù)學(xué)校的要求和具體情況，筆試的最終分?jǐn)?shù)也可以提高。?

分?jǐn)?shù)分布奇怪怎么辦

在少數(shù)情況下，一個班的分?jǐn)?shù)會出現(xiàn)奇怪的分布，例如，有一兩個特別優(yōu)秀的學(xué)生，他們得到非常高的分?jǐn)?shù)，會導(dǎo)致其他同學(xué)的相對分?jǐn)?shù)太低；或者學(xué)校對分?jǐn)?shù)段的人數(shù)有規(guī)定，或者領(lǐng)導(dǎo)要求把某個不及格的分?jǐn)?shù)變成及格(我聽說過兩次這樣的情況)。

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

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

團(tuán)隊項目的展示評審階段如何打分

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

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

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

?具體方法：

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

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

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

評審階段的打分安排：

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

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

? ? ? 誰來做復(fù)審人：老師，助教，每個團(tuán)隊選一個本團(tuán)隊的代表

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

? ? ? 復(fù)審人看什么：

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

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

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

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

? ? ? 復(fù)審怎么做：

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

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

軟件 = 程序 + 軟件工程

軟件_{(的質(zhì)量)} = 程序_{(的質(zhì)量)}+ 軟件工程_{(的質(zhì)量)}

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

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

高性能

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

可靠性 & 穩(wěn)定性 & 可用性

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

安全性

用戶的業(yè)務(wù)數(shù)據(jù)是具有非常高的商業(yè)價值，如果被泄露或篡改將會帶來重大損失。安全性是軟件系統(tǒng)的一個重要的指標(biāo)，也是架構(gòu)設(shè)計的一個重要目標(biāo)。團(tuán)隊項目考察：軟件是怎么保護(hù)用戶隱私的？軟件能防止外力入侵系統(tǒng)么？

靈活性 & 可擴(kuò)展性

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

易用性

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

可維護(hù)性

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

經(jīng)常有人說：“架構(gòu)是系統(tǒng)非功能性需求的解決辦法的集合”，如果同學(xué)們自稱“架構(gòu)好”，那就用數(shù)據(jù)來證明。

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

3) 助教收集所有復(fù)審人的名次信息， 按平均名次排列， 并給予分?jǐn)?shù)(再次強調(diào)：小組互相評名次，不打分，助教最后打分)。

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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。