// 上一篇：题目设计、点评和评分
// 下一篇：超链接
教学里，建立清晰明确的评分规则并且一开始就公布，对于教师、助教、学生都是重要的。
公布时机
在课程开始的时候，就需要确定并公布评分机制，随着课程展开，需要做的是做细节上的修订和严格的执行。为什么要第一时间公布明确的评分规则？ 因为：
- 规则不明确，教师就不清楚助教会怎样评分，设计题目的时候对于一个题目的难度、周期和重要检查点会少了一个重要的参照点。
- 规则不明确，助教在评分过程中便会拿捏不准，不知道基准在哪，怎样使用工具。
- 规则不明确，学生会找借口，寻找规则的漏洞，容易滋生南郭先生。
阶梯分布
那么，明确了评分机制的公布点、修订点以及执行点之后，我们就要讨论评分机制本身如何设计更合理。《构建之法》在【给任课老师和助教的建议】一节里对此有充分的讨论，提出应该建立简明公开的原则：
把每次作业的表现分为N档：
- 最优秀的几个同学得满分
- 第2档的同学得1/2的分数
- 第3档的同学得1/3的分数
- 依此类推...
- 迟交的作业0分
- 不交作业倒扣分
传统的【大家都能及格】的分数分布看上去皆大欢喜，实则对优秀学生极不公平。根据上面的机制，可以在每次作业布置的时候，都重复贴上以下内容：
## Deadline：
2017-3-8 12:00AM，以博客发表日期为准。
## 评分基准:
- 按时交 - 有分，检查的项目包括后文的N个方面
- 题目要求
- 代码提交
- 博文规范
-
- 晚交 - 0分
- **迟交一周以上 - 倒扣本次作业分数**
- 抄袭 - 0分
## 题目要求
...
## 代码提交
...
## 博文规范
...
## ...
每次都有明确的截止日期和具体要求，这样就能实现清晰明确的评分规则的目的。 参考下面的实际例子：
http://www.cnblogs.com/happyzm/p/6472120.html
累加映射
例如，具体到软件工程这个课程上，《构建之法》里的分数设计是这样的：
原始总分=
平时成绩
+ 个人成绩
+ 结对项目成绩
+ 团队项目Alpha成绩
+ Alpha阶段个人贡献分
+ 团队项目Beta成绩
+ Beta阶段个人贡献分
总分=原始总分线性映射到百分制到【100..50】这一区间。对于研究生可以考虑映射到【100..60】这个区间。一般来说，这几个不同阶段的分数占比不同，原始总分由如下构成：
- 个人项目50分（博客+项目代码）
- 结对项目100分（博客+项目代码）
- 团队Aalpha满分200分，
- 团队Aalpha 50分的个人贡献分
- 团队Beta满分200分
- 团队Beta50分的个人贡献分
详细展开请参考这份精细的设计：http://www.cnblogs.com/SivilTaram/p/5656582.html
注意：此处建议使用项目，而不是作业，这在概念上是有差别的，项目是持续开发的，有更长生命周期的，是主动性的action。作业则可能是短周期短，被动性的task。因此：
课程有项目 （个人，结对，团队）， 项目有作业， 作业分为代码作业，和博客作业。
评分工具
上面的公式，助教可以建立一个Excel表格，通过线性映射公式，自动化计算。例如
| 学号 | 个人项目1 | 结对项目1 | 案例分析 | 团队项目Alpha | 团队项目Beta | 原始总分 | 总分 |
|---|---|---|---|---|---|---|---|
| 001 |
具体的项目次数由教师、助教协商，例如，有些学校在重要节点之间插入一些适当的工具操作练习。练习比作业的权重小，比如个人项目是50分，练习只有10分。但是练习可以目的明确地训练某个具体工具的使用，比如：
- 数据库建模工具
- UML里画一个UserCase
- Git的操作
- IDE的安装
- 思维导图的练习...
单次项目
具体到操作里，教师和助教还会有一些不明的地方：一次作业的内容上如何评分？可以采用和整体一致的方案：针对一次作业的checklist做分类评分后累加映射，我们直接看表格：
| 学号 | 题目要求 | 代码提交 | 博文规范 | 工具使用 | 单次原始总分 | 单次总分 |
|---|---|---|---|---|---|---|
| 001 |
这是一个子表，子表里对单次作业的checklist做分类评分，分类评分的时候，可以累加每个单项分数后计入单次原始总分，线性映射到单次的分数范围（例如，团队Alpha是200分）。同样的，可以通过Excel公式做自动计算工作。教师和助教可以协商checklist的权重。
另外，针对团队项目这样细节比较复杂的，设计单次作业每个单项分数的时候，也可以每个单项按10分去给，然后乘以每个部分的权重，映射到单次分数，可以看作是一个评分放大镜。
截断问题
评分规则会遇到边界问题，在实践中会有下面两种特殊情况，特别是存在一些特别拖后腿的同学的时候：
- 总分是负分
- 总分很低，虽然不是负分，但分数太低，如果以这么低的分数作为 MIN ，则总体分数会集中到80以上。
这两种情况如果也参与映射，显然不合理，要怎样解决呢？在教学讨论中，@SoftwareTeacher建议如下：
第一种方式，在不改变映射规则的基础上，存在如何抛弃那些特别低分的同学的问题， 以及各种项目得分比重是否合理的问题。教师和助教可以根据具体情况决定，例如：
- 原始总分是负分的直接不参与线性映射，直接映射为0分。
- 原始总分很低的，和其他同学明显存在间断的，也不参与线性映射，在0-50分之内选取合适的范围映射。
第二种方式，改变映射规则，改为先映射， 再累计的评分方式。具体来说，是这样的：
- 规定个人项目占10分， 结对项目占20分，团队的alpha/beta 各占35 分。 加起来就100 分了。
- 现在我们把所有人的个人项目的原始分（可能有多个个人作业）做单变量的线性映射：
- 最高分 -> 10 分
- 其它分数按 【最高分/10分】的比率来映射（负分就映射到0 分）。【score=orign_score*max_orign_score/10 】
- 把各个阶段的分数映射完之后，再加起来。
这个做法也有优缺点(Pros and Cons)：
- 好处是不太用考虑 “从哪里截断原始分的映射” 这个问题。这个转换没有下限， 所以不用考虑原始分的下限应该在哪里。
- 坏处是这样通常最好的同学不会得100 分（除非他每一项目都是最高分），而且在课程中不能看出大家映射的得分， 没有能够给大家直接的感觉，以及显示大家你追我赶的数据。
以上两种针对截断问题的解决方法，提供给教师和助教在课程开始设计评分规则的时候选择。
评分展示
助教在截止日期时，及时发布评分博客，评分博客由多个部分构成，例如下面这个组合：
- 题目：给出教师布置题目的原始链接
- 项目完成情况：简要说明总共多少人，提交的人数，未提及的人数
- 总得分映射到百分制的排名：这是一个根据映射分做的柱状图，也即到目前为止的得分排行榜
- 得分情况：包含了每次项目原始分，累加原始分，最后映射分的一个表格
- 评分标准：详细列出本次项目的评分标准
- 助教想说：助教针对本次项目提交情况的综合分析和建议
- 评分明细：本次项目评分明细的子表
完整的例子请参考：http://www.cnblogs.com/schaepher/p/6582306.html
其他课程
有的教师认为只有软件工程课程才适合这样评分。其实，如果是编程语言课，除了在环节设计上不同之外，其他的设计都是同样适用的：
- 简明公开
- 累加映射
- 严格执行
checklist
首先，分数的设计机制，也能倒推在题目的设计上。设计题目的时候，教师和助教就需要对那些模糊的地方进行细化，对难度超过学生水平的地方做拆分，否则学生因为觉得模糊或困难而都不做作业，或随便应付，便无法达到有效训练的目的。
其次，设计checklist的时候，要有区分度。不能所有的条目都平均分配，这就涉及到对一个环节里哪些知识点、哪些方法是重要的，是突出强调。以及，设计这些条目的目的是什么？还是一样的道理，条目设计要有阶梯分布，检查的时候要注重形式和内涵的契合，例如，要求用思维导图，但是要看他用思维导图解决了什么问题，是否为单个环节的最终目标服务，设计的条目文本最好也能恰当表达这层意思。
第三，要回归相关课程的本质。例如对于软件工程，“还是要回到软件工程的本质， 例如画 UML 图， 有什么用？ 画了有人看么？ 给谁看的？ 代码变了，UML 要跟着变么？ 软件工程最后的产品是代码， 那么中间产生的各种文档的目的是啥？”（--xinz）。这样在设计checklist和评分的时候，可以有的放矢。
技术支持
最后，博客园的班级博客在评分工具，在技术上也许可以对此建模，提供工具支持。