软件工程课的分数系统，和打分方法

考考考，老师的法宝；分分分，学生的命根。以《构建之法》为核心的软件工程课已经在全国几十个学校开展了好几年，由于采用 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	...	...