软工+C(2017第2期) 分数和checklist

// 上一篇：题目设计、点评和评分

// 下一篇：超链接

---

教学里，建立清晰明确的评分规则并且一开始就公布，对于教师、助教、学生都是重要的。

公布时机

在课程开始的时候，就需要确定并公布评分机制，随着课程展开，需要做的是做细节上的修订和严格的执行。为什么要第一时间公布明确的评分规则？ 因为：

1. 规则不明确，教师就不清楚助教会怎样评分，设计题目的时候对于一个题目的难度、周期和重要检查点会少了一个重要的参照点。
2. 规则不明确，助教在评分过程中便会拿捏不准，不知道基准在哪，怎样使用工具。
3. 规则不明确，学生会找借口，寻找规则的漏洞，容易滋生南郭先生。

阶梯分布

那么，明确了评分机制的公布点、修订点以及执行点之后，我们就要讨论评分机制本身如何设计更合理。《构建之法》在【给任课老师和助教的建议】一节里对此有充分的讨论，提出应该建立简明公开的原则：

把每次作业的表现分为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分去给，然后乘以每个部分的权重，映射到单次分数，可以看作是一个评分放大镜。

截断问题

评分规则会遇到边界问题，在实践中会有下面两种特殊情况，特别是存在一些特别拖后腿的同学的时候：

1. 总分是负分
2. 总分很低，虽然不是负分，但分数太低，如果以这么低的分数作为 MIN ，则总体分数会集中到80以上。

这两种情况如果也参与映射，显然不合理，要怎样解决呢？在教学讨论中，@SoftwareTeacher建议如下：

第一种方式，在不改变映射规则的基础上，存在如何抛弃那些特别低分的同学的问题， 以及各种项目得分比重是否合理的问题。教师和助教可以根据具体情况决定，例如：

1. 原始总分是负分的直接不参与线性映射，直接映射为0分。
2. 原始总分很低的，和其他同学明显存在间断的，也不参与线性映射，在0-50分之内选取合适的范围映射。

第二种方式，改变映射规则，改为先映射， 再累计的评分方式。具体来说，是这样的：

1. 规定个人项目占10分， 结对项目占20分，团队的alpha/beta 各占35 分。 加起来就100 分了。
2. 现在我们把所有人的个人项目的原始分（可能有多个个人作业）做单变量的线性映射：
   • 最高分 -> 10 分
   • 其它分数按 【最高分/10分】的比率来映射（负分就映射到0 分）。【score=orign_score*max_orign_score/10 】
3. 把各个阶段的分数映射完之后，再加起来。

这个做法也有优缺点(Pros and Cons)：

1. 好处是不太用考虑 “从哪里截断原始分的映射” 这个问题。这个转换没有下限， 所以不用考虑原始分的下限应该在哪里。
2. 坏处是这样通常最好的同学不会得100 分（除非他每一项目都是最高分），而且在课程中不能看出大家映射的得分， 没有能够给大家直接的感觉，以及显示大家你追我赶的数据。

以上两种针对截断问题的解决方法，提供给教师和助教在课程开始设计评分规则的时候选择。

评分展示

助教在截止日期时，及时发布评分博客，评分博客由多个部分构成，例如下面这个组合：

• 题目：给出教师布置题目的原始链接
• 项目完成情况：简要说明总共多少人，提交的人数，未提及的人数
• 总得分映射到百分制的排名：这是一个根据映射分做的柱状图，也即到目前为止的得分排行榜
• 得分情况：包含了每次项目原始分，累加原始分，最后映射分的一个表格
• 评分标准：详细列出本次项目的评分标准
• 助教想说：助教针对本次项目提交情况的综合分析和建议
• 评分明细：本次项目评分明细的子表

完整的例子请参考：http://www.cnblogs.com/schaepher/p/6582306.html

其他课程

有的教师认为只有软件工程课程才适合这样评分。其实，如果是编程语言课，除了在环节设计上不同之外，其他的设计都是同样适用的：

• 简明公开
• 累加映射
• 严格执行

checklist

首先，分数的设计机制，也能倒推在题目的设计上。设计题目的时候，教师和助教就需要对那些模糊的地方进行细化，对难度超过学生水平的地方做拆分，否则学生因为觉得模糊或困难而都不做作业，或随便应付，便无法达到有效训练的目的。

其次，设计checklist的时候，要有区分度。不能所有的条目都平均分配，这就涉及到对一个环节里哪些知识点、哪些方法是重要的，是突出强调。以及，设计这些条目的目的是什么？还是一样的道理，条目设计要有阶梯分布，检查的时候要注重形式和内涵的契合，例如，要求用思维导图，但是要看他用思维导图解决了什么问题，是否为单个环节的最终目标服务，设计的条目文本最好也能恰当表达这层意思。

第三，要回归相关课程的本质。例如对于软件工程，“还是要回到软件工程的本质， 例如画 UML 图， 有什么用？ 画了有人看么？ 给谁看的？ 代码变了，UML 要跟着变么？ 软件工程最后的产品是代码， 那么中间产生的各种文档的目的是啥？”（--xinz）。这样在设计checklist和评分的时候，可以有的放矢。

技术支持

最后，博客园的班级博客在评分工具，在技术上也许可以对此建模，提供工具支持。