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

考考考，老师的法宝；分分分，学生的命根。
 
以《构建之法》为核心的软件工程课已经在全国几十个学校开展了好几年，因为采用 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：每一个软件项目均可能是很好的软件工程案例， 但同窗们对于其余团队的项目不太关心， 只是最后评审的时候看看别人软件的界面，草草给一个分数，浪费了不少的学习机会。  

解决：把点评作成有趣的场景， 让同窗们专一于分析各个项目的成功的可能性， 让同窗们本身用批判的眼光分析问题，跟踪项目的进展。 

 
具体方法：

1. 让全部团队根据  NABCD 本身审核一下本身的团队项目，把 NABCD 元素加到本身的团队博客的项目说明中， 同时说明预期的 “项目发布后3天的用户量”。  能够给机会让同窗们修改团队项目，全部团队发表博客。
2. 而后， 全部团队写一个博客， 依次评价其余团队的项目立项 NABCD， 排名次 （名次没有并列）。  助教统计全部名次，  名次最低的团队必须作出重大修改， 包括选一个新的项目。
3. 能够用风险投资作比喻 ，  每一个学生都是有钱的风投资本家，  要给这个班级的全部项目投资， 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	...	...

 

 

3） 助教收集全部复审人的名次信息， 按平均名次排列， 并给予分数（再次强调：小组互相评名次，不打分，助教最后打分）。

4） 这个展现做业的满分是 100 分，其他名次按照阶梯递减（例如，每一个阶梯是 10 分或 5 分），取决有多少团队参加了评比，阶梯要拉开，也要保证付出了努力的团队得到至关于及格的分数。 也能够分类评比，例如，全部自选项目在一类，全部作学校老师布置的项目在一类，全部 “微信小程序”类型在一类，等。