月份：2009年9月

这是一篇迟到的文章，而且迟到的非常厉害。从2008年决定申请到现在，已经过去了一年零4个月，从拿到AD，也已经过去了4个多月。一直想写点什么，但总是因为种种原因耽搁下来。

回首历时一年的申请过程，有些事情已渐渐模糊，趁着还有一些记忆，赶快写下来吧。北欧是个好地方，但是遗憾是我和宝贝没能申请到同一所学校。好在挪威和瑞典相隔并不遥远。首先说说结果吧，我们最终拿到了挪威NTNU和瑞典KTH的AD。

话说2008年初，动了出国读书的念头，由于我们都在工作，时间非常紧张，没有考Toefl GRE的可能，在这种前提下，我们限定了目标范围：接收IELTS的地区。这包括欧洲、新加坡、澳大利亚和加拿大。那时我们有很现实的目标，拿学历、少花钱、出去玩玩。在这个大背景下，我们选择了北欧，因为北欧的学校免学费，生活费也不算很高。在这里要提两位好朋友，Maple和Mounttai，他们帮我们推荐学校、修改申请材料、推荐新加坡管理大学（SMU），虽然最终没能去成新加坡，还是要好好谢谢你们！

• 2008年6月：决定出国读书
• 2008年9月：考雅思
• 2008年11月30日：挪威NTNU预申截止
• 2009年1月15日：瑞典网申截止
• 2009年2月1日：挪威NTNU正式申请截止
• 2009年2月15日：瑞典材料寄送截止
• 2009年5月1日：挪威NTNU出结果
• 2009年5月9日：瑞典第一轮出结果
• 2009年8月：启程

• 瑞典：KTH(皇家理工), CTH(查尔摩斯), LIU(林雪平), UU(乌普萨拉)
• 挪威：NTNU(挪威科技大学)
• 新加坡：SMU(新加坡管理大学)

这就是我们这一路走来的时间表以及投递过材料的学校。我们所有的材料寄送，几乎都是卡在截止日期前几天的时间，可谓如履薄冰。申请过程也极其不易，每天下班回家就要8点了，准备材料的时间被压缩到不能再压缩，还好Mounttai和Hari帮我们修改了几次CV和Personal Statement，要不真的搞不定。

关于选校，或者选专业，我真的说不出什么，因为瑞典的学校是走统一申请，寄送一次材料可以选择4个学校/专业，说实话，这四所学校是比较热门的，而我根本没有时间研究所有的学校，这4所，就是我所知道的4所了。挪威的NTNU，完全是因为临近截止前2天，Maple告诉我有这么一个学校，我想都没想就申请了，因为可以在网上预申请。SMU，因为Maple和Mounttai都在那里。至于专业，我学计算机的，工作中有项目管理经验，所有的专业除了计算机，就是项目管理了。北欧读书转专业是不太可能的。

其实关于选校，我的建议是如果你有时间，还是要好好做做功课，找到你最喜欢的学校、最想学的专业，这很重要。因为它很有可能会决定你的职业生涯。

关于寄送材料，其实可以通过航空挂号信寄，丢失的概率并不大，完全可以接受。只是比较慢，2~3周才能到。但是便宜啊，应该只要30块钱左右就能寄到了。而我们因为总是赶最后的截止日期，因此全部使用的是TNT全球快递，每次寄送都是260块钱左右，最后算算下来，光邮寄费用，我一个人就花掉了1500多，相当奢侈。因此强烈建议想省钱的同学，尽早准备，提前1个月的话便可以使用航空挂号。

关于考雅思，雅思不难，背背机经，练几次作文，背背范文（除非你想拿到6.5以上的作文)，突击下口语，6.5应该没问题，我当时因为听力和口语运气很好，最后拿到了7分的好成绩。单词还是要背的，毕竟雅思阅读还是很有难度的，量大，而且全凭识别单词的能力了。考雅思要提前不少时间报名，1、2周之内的报名基本没戏，要提前安排。雅思出成绩要2周左右的时间，寄送成绩单还有2周左右，因此最晚最晚也要在材料截止前1个半月考雅思了，否则就太紧张，风险太大了。

关于等待，今年2月份，我们把材料都寄出去了，总算可以清闲下来，等待是非常煎熬的一件事，以至于后来慢慢麻木了，从一开始天天从网上查状态，都后来半个月都懒得看一下。这段时间心态要放平稳，该干啥干啥，否则难熬，还伤神。

AD，我好像是2009年5月1日拿到的，一封Congratulations的邮件带给了我一份生日大礼，反复读了很多次，虽然天天盼，真到这一刻，反而有点不相信自己的眼睛，因为说实话，在等待的过程中，我蹭无数次告诉自己，如果失败了，生活还要继续，现实还要面对。然而令人郁闷的是，宝贝并没有收到NTNU的AD。随后的一周，我们一起等待瑞典的结果。

其实早在4月中旬，宝贝就受到LIU的非正式通知，只是因为LIU在第二志愿，因此还要看KTH的结果。后来和晓伟聊过，幸亏没去林雪平，那个城市太小了，太压抑了，还是斯德哥尔摩好，人多，也热闹。5月9日，好像是这一天，瑞典的申请结果下来了，我还记得那天我是下午下班前，大概5点半多一点的样子，我看到了结果，高兴地不得了。但是因为当时在单位还没有跟大家讲要走，只能匆匆忙忙收拾了东西，除了门就打电话给宝贝~~ 我们可以一起去周游世界了！

幸运的是我们都拿到了AD，但是美中不足的是我们在不同的城市——挪威的特隆赫姆和瑞典的斯德哥尔摩。前段时间我去了一次，火车15个小时，往返1400多块钱。过几天宝贝也要过来玩了，飞机还是挺快的。

我们的申请就这样稀里糊涂的结束了，这其中心情的变化难以言表，如果你没有申请过，你不可能知道那种等待的煎熬和艰辛。但是走过来，回头看，我想告诉你们的是，其实并不难，只要你坚持下去，不要放弃，一定会雨过天晴的。

特隆赫姆的彩虹可以从地平线这端延伸到那一端；斯德哥尔摩的老城非常有古老的味道。2009年8月3日，2009年8月17日，我们分别踏上旅途，降落在一个陌生的城市，开始新的征途。

此时此刻的窗外，阳光明媚，然而却是一个星期连阴雨后的第一缕阳光。我并不因为这里的天气而感到郁闷，因为我知道，即使是一个月都在下雨，也总有阳光普照的那一天。

今年终于完成了风险管理这门课程前两周的练习，总算赶上一门课程的进度，当初学概率用英文还一知半解的东西，现在竟要用英文学习。好在现在所学的概率只是一些简单理论的应用，而计算则大部分由已经编好的程序完成。

在正式开始本文重点内容之前，先简单总结一下所学的内容。

本文导读：

1. 关于概率
2. 关于计划分析（Schedule analysis）
3. 想法：从概率的角度分析程序出错的可能性
4. 理论联系实际：应用构想
5. 附录:相关资料

关于概率：

1. 概率的基本概念：随机事件、样本空间、概率定义、随机变量
2. 贝叶斯法则（Bayes rule）
3. 概率分布：函数、期望值、中值、标准差、双期望值定理（Double Expectation）
4. 常用概率分布曲线：Normal、Exponential、Triangular、PERT Distribution
5. 概率分布的运算：Sum, Product, Maximum

关于计划分析（Schedule analysis）：

1. 网络图：起点、终点、活动、里程碑、不确定性、虚拟节点、顺序
2. 目的：为整个项目过程、部分活动或里程碑建立累计的概率分布函数；衡量项目中某个活动导致整个项目延迟的可能性；
3. Critical Path Method(CPM)：利用Most likely value找出网络中的关键路径（最长），但是此方法缺陷是只能用于处理确定的活动，无法处理过程中的不确定性因素。
4. Program Evaluation and Review Technique(PERT)：用于将不确定性因素考虑在内的关键路径上的衡量，但是此方法的缺陷在于，如果存在多条期望时间重叠的路径，此方法无法处理。
5. Successive Schedule Planning(SSP)：将项目过程中所有活动纳入分析范围，考虑到各个节点、路径的不确定因素，可以完整的分析和衡量整个项目过程消耗时间的方法，最终建立一个累积的概率分布曲线。
6. Monte Carlo Simulatoin：通过大量随机实验，获得数据绘制分布曲线，从曲线上读数。

这门课程头两张的内容比较抽象，练习也都是概念上的计算题。从这两周的课程中我认识到一点，从不确定性以及概率的角度看待工作活动似乎更加合理。倒不是说一定要用这些公式或模型去套用，只是因为工作中不确定性的因素太多，你要接受它们，并充分估计不确定性因素所带来的负面影响。

想法：从概率的角度分析程序出错的可能性

工作的时候，一直有个想法。想法的背景是这样的：因为几乎每个新写的程序都是独特的，相当大数目的程序从开发到传输的生命周期不超过40人时，甚至不超过10人时。在如此短促的开发过程中，几乎没有可能应用所谓的软件工程或质量保证什么的，因为那样会极大的增加成本。

我的想法是，能否用一种自动化的方法，衡量程序的质量或复杂程度？我曾经在工作中通过对程序文法分析获得程序中的IF、LOOP、CHECK、SUBROUTINE等代码块的数量，为每一种代码块设定一个参数，将各方面数据做累加，用于衡量程序的复杂度。当时遇到了一些问题，就是无法将各种代码块有效、合理的组合在一起，并且没能设定合理的参数。

应用构想

这个想法现在看来仍然值得继续尝试，在这两周学习的背景知识下，作出如下调整：

• 分析历史数据（变更、版本），获取一部分数量的样本数据，50~100个程序，其中包含各类以及小、中、大规模的程序，按如下方式记录，此表格中的缺陷概率(M)将作为特征代码缺陷概率的中值（MEAN），其中 缺陷概率= 缺陷次数/出现次数，缺陷比重=缺陷次数/缺陷总次数：
  

  特征代码	出现次数	缺陷次数	缺陷概率(M)	缺陷比重
  IF…ELSE…	150	9	6%	20.9%
  WHILE	50	2	4%	4.7%
  CHECK	15	4	26.6%	9.3%
  SELECT…	300	25	8.3%	58%
  DELETE…	40	3	7.5%	6.9%
  …
  TOTAL/AVG	555/111	43/8.6	10.48%	100%

• 假定我们有一个程序：Program A，其中包含各种特征代码，相关数据如下表所列：
  

  特征代码	正确概率	出现次数	正确概率的n次方，n=出现次数
  IF…ELSE…	94%	2	0.8836
  WHILE	96%	3	0.884736
  CHECK	73.4%	1	0.734
  SELECT…	91.7%	5	0.648405
  DELETE…	92.5%	4	0.732094
  		概率乘积	P(A)=27%（整个程序的正确概率）

  事实上，在本例中，我们将本程序分解为15个相互独立的随机事件，那么所有缺陷事件均不发生的概率就是每个事件正确概率的乘积。

• 根据工作需要，设定P(A)的临界值，如当P(A)<=40%时，需经过非程序员本人的质量测试方可传输。

这其中的参数（主要是缺陷概率）可通过对历史数据的观察获得初始值，并随项目进展更新，缺陷概率随开发人员水平不同而变化，随开发时间不同而变化，本构想尚未对其他参数进行设定，但增加相应参数则可以扩展模型的适用范围及准确度。

此工具在工作中的应用，可以自动、快速的分析程序结构，依据历史数据计算程序出错的概率，开发人员可直观判断一个程序的风险，并增加相应的质量保证活动。对于短周期、小规模开发、频繁变更的项目尤其有效。若能在应用的同时增加数据的收集，可用于矫正模型参数以及评估质量改进的效果。

目前，这还只是一个构想，写到这里，我想我又犯了一个错误：在写下这些构想之前，没有翻阅资料，也许这些想法早有人实现甚至有成熟的工具，也有可能这根本就是没有意义的胡言乱语，总之下次，我会在构想一件事之前，看看别人是怎么想的。

附录：一些相关资料

• 软件质量管理实践：软件缺陷预防、清除、管理实用方法 7.6 缺陷度量
• 软件代码缺陷分类及其应用