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

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

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

本文导读:

  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%时,需经过非程序员本人的质量测试方可传输。

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

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

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

附录:一些相关资料

发表评论

电子邮件地址不会被公开。 必填项已用*标注