战场态势信息量的一种度量方法
第３６卷第１期２０１４年２月
指挥控制与仿真
ＣｏｍｍａｎｄＣｏｎｔｒｏｌ＆Ｓｉｍｕｌａｔｉｏｎ
Ｖｏｌ ３６一Ｎｏ １Ｆｅｂ ２０１４
文章编号：１６７３?３８１９（２０１４）０１?０００１?０４
战场态势信息量的一种度量方法?
张东戈１，孟一辉２，陶九阳１
（１．解放军理工大学指挥信息系统学院，江苏南京一２１０００７；
２．解放军驻太原铁路局军事代表处，山西太原一０３００１３）
摘一要：恰当地度量战场态势信息量，是作战指挥二指控信息系统二通信系统等众多研究领域中重要的基础问题三从态势感知出发，将态势信息区分为彼此独立无关的 态 信息和 势 信息，结合Ｓｈａｎｎｏｎ信息论思想，提出了综合刻画态势信息量大小的方法，解决了传统战场态势信息量度量方法中未能包含态势变化趋势信息的问题三在此基础上，给出了双节点要达到协同必须满足的态势感知一致性条件三
关键词：战场协同；指挥控制；态势信息量；解析定义；形式化方法
中图分类号：Ｅ２１１一一一一文献标识码：Ａ一一一一ＤＯＩ：１０．３９６９／ｊ．ｉｓｓｎ．１６７３?３８１９．２０１４．０１．００１
ＡｍｏｕｎｔＭｅａｓｕｒｅｍｅｎｔｏｆＳｅｌｆ?ｉｎｆｏｒｍａｔｉｏｎｏｎｔｈｅＢａｔｔｌｅｆｉｅｌｄＳｉｔｕａｔｉｏｎＡｗａｒｅｎｅｓｓ
ＺＨＡＮＧＤｏｎｇ?ｇｅ１，ＭＥＮＧＨｕｉ２，ＴＡＯＪｉｕ?ｙａｎｇ
１
（１．ＣｏｌｌｅｇｅｏｆＣｏｍｍａｎｄＩｎｆｏｒｍａｔｉｏｎＳｙｓｔｅｍｓ，ＰＬＡＵｎｉｖｅｒｓｉｔｙｏｆＳｃｉｅｎｃｅａｎｄＴｅｃｈｎｏｌｏｇｙ，Ｎａｎｊｉｎｇ２１０００７；
２．ＭｉｌｉｔａｒｙＲｅｐｒｅｓｅｎｔａｔｉｖｅＯｆｆｉｃｅｏｆＴａｉｙｕａｎＲａｉｌｗａｙＢｕｒｅａｕ，Ｔａｉｙｕａｎ０３００１３，Ｃｈｉｎａ）
Ａｂｓｔｒａｃｔ：Ｔｈｉｓｉｓａｎｉｍｐｏｒｔａｎｔｂａｓｉｃｐｒｏｂｌｅｍ，ｎａｍｅｌｙｔｏｐｒｏｐｅｒｌｙｍｅａｓｕｒｅｔｈｅａｍｏｕｎｔｏｆｉｎｆｏｒｍａｔｉｏｎｏｎｔｈｅｂａｔｔｌｅｆｉｅｌｄｓｉｔｕａ?ｔｉｏｎａｗａｒｅｎｅｓｓ，ｗｉｔｈｉｎｃｏｍｂａｔｃｏｍｍａｎｄｆｉｅｌｄ，Ｃ２ｉｎｆｏｒｍａｔｉｏｎｓｙｓｔｅｍｓｄｅｓｉｇｎ，ｃｏｍｍｕｎｉｃａｔｉｏｎｓｓｙｓｔｅｍｓｕｓａｇｅ．Ｆｒｏｍｓｉｔｕａ?ｔｉｏｎａｌａｗａｒｅｎｅｓｓｐｅｒｓｐｅｃｔｉｖｅ，ｗｅｄｅｆｉｎｅａｓｅｐａｒａｔｅｉｎｄｅｐｅｎｄｅｎｔ ｓｔａｔｅ ａｎｄ ｔｒｅｎｄｓ ．ｉｔｅｘｐｒｅｓｓｅｓｔｈｅｓｉｔｕａｔｉｏｎｗｈｉｌｅｃｏｍｂｉ?ｎｉｎｇｔｈｅｍｔｏｇｅｔｈｅｒ．ＡｃｃｏｒｄｉｎｇｔｏＳｈａｎｎｏｎｉｎｆｏｒｍａｔｉｏｎｔｈｅｏｒｙｉｄｅａｓ，ｗｅｐｒｏｐｏｓｅａｎｉｎｔｅｇｒａｔｅｄａｐｐｒｏａｃｈｔｈａｔｃａｎｇｉｖｅｍｅａｓｕｒｅ?ｍｅｎｔｏｆｔｈｅａｍｏｕｎｔｏｆｓｅｌｆ?ｉｎｆｏｒｍａｔｉｏｎ．Ｉｔｓｏｌｖｅｓａｐｒｏｂｌｅｍｔｈａｔｔｒａｄｉｔｉｏｎａｌｍｅｔｈｏｄｓｃａｎｎｏｔｃｏｎｔａｉｎｔｒｅｎｄｉｎｆｏｒｍａｔｉｏｎ．Ｏｎｔｈｉｓｂａｓｉｓ，ｗｅｇｉｖｅｔｈｅｃｏｎｓｉｓｔｅｎｃｙｃｏｎｄｉｔｉｏｎｆｏｒｔｗｏ?ｎｏｄｅｃｏｏｒｄｉｎａｔｉｏｎｏｆｓｉｔｕａｔｉｏｎａｌａｗａｒｅｎｅｓｓ．
Ｋｅｙｗｏｒｄｓ：ｂａｔｔｌｅｆｉｅｌｄｃｏｏｒｄｉｎａｔｉｏｎ；ｃｏｍｍａｎｄａｎｄｃｏｎｔｒｏｌ；ｓｅｌｆ?ｉｎｆｏｒｍａｔｉｏｎｉｎｓｉｔｕａｔｉｏｎａｗａｒｅｎｅｓｓ；ａｎａｌｙｔｉｃｅｘｐｒｅｓｓｉｏｎ；ｆｏｒｍａｌｍｅｔｈｏｄ
一收稿日期：２０１３?１０?０８
修回日期：２０１３?１０?２９
?基金项目：国家自然科学基金（６１１７４１９８）；２０１１年度全军
军事学研究生课题（２０１１ＪＹ００２?１６３）作者简介：张东戈（１９６５?），男，河北安平人，教授，研究方
向复杂军用系统分析三
孟一辉（１９８１?），男，硕士，工程师三陶九阳（１９８３?），男，硕士，讲师三
一一如何恰当地度量战场态势信息量的大小，是研究战场指挥员态势感知负载，计算指挥信息系统态势信息处理能力的基础三战场上，通用作战态势图（ＣｏｍｍｏｎＯｐｅｒａｔｉｏｎａｌＰｉｃｔｕｒｅ，简称ＣＯＰ）［１］是度量态势感知能力的基础［２］，是刻画战场态势环境的主要方式之一三如果态势图中包含显示的信息过少，会影响指挥员对态势的认知水平；如果过多，则会增加指挥员用于认知的时间，导致决策速度下降三一幅态势图中包含了多少态势信息，如何度量这些态势信息所包含的信息量大小就成为一个亟待解决的问题三
战场指挥员若想真正恰当准确地认知态势，他对态势的认知既要包括对 态 的信息的认知，又要包含对 势 的信息的认知三目前，大多数方法只包含对 态 的度量，未能体现战场态势变化趋势的部分，而这
部分却是耗费指挥员认知资源最大的一部分三因此，要准确描绘态势信息，就必须同时描绘出态的信息和势的信息三Ｓｈａｎｎｏｎ信息论是度量概率信息中信息量多少常用的方法［３］，本文利用Ｓｈａｎｎｏｎ信息论思想，形式化定义了 态信息量 的大小和 势信息量 的大小，进而给出了态势信息量的度量方法，为态势感知特性的解析计算提供了重要的理论基础三
１一战场态势信息描述
对战场环境实施有效态势感知是指挥员完成决策的基础三按照Ｒｉｌｅｙ等人的观点，２００６年人机工效学会（Ｅｒｇｏｎｏｍｉｃｓ）将态势感知（ＳｉｔｕａｔｉｏｎＡｗａｒｅｎｅｓｓ）定义为 持续地接收到足够大量的告警信息 ［４?６］，同时态势感知也指Ｅｎｄｓｌｅｙ１９９５年所定义的 感知者知道现在发生着什么 ［７］三由此，人们提出的一个基础性问题就
是， 足够大量的告警信息 或者是 知道现在发生着什么 这其中到底包含着多少可以度量的 态势信息量 ，只有知道了这样一个参量，才有可能回答 提供多少态势信息量，就算是足够大量的告警信息 ，或者是 需要提供多少态势信息量，感知者就可以知道现在发生着什么 三度量态势信息量大小所面临的困难主要
软件度量总结(精)
软件度量总结 这次总结的结构比较简单,就是按照五个章节分别阐述了自己的理解。 一.软件度量的应用范围。 经过这一阶段的学习,我认为想要明白软件度量,首先要分清度量和测量的区别。度量具有前置性,它提供了一种定量研究软件问题的方法;测量具有实时性或后置性,主要集中在给度量提供数据或者处理数据的方法上。由于软件工程强烈的不确定性,使得软件工程的精确测量困难重重,但软件度量主要研究的是可能性的规律,通过概率和统计学的研究,寻找事物内在的规律。其并不具备 1+1=2的特征, 而是研究在多大可能性上这个结论是合理的,因为软件的主体是人,具有概率属性,设备和材料容易度量,但人很难度量。软件度量的主要作用是评估状况、跟踪进展情况、评价产品有效性和改进设计和过程的质量。定性分析可以提供迅速地判断能力,但定性分析终究需要定量分析的验证与支持,否则其结果很可能成为无目之本,出现错误。 软件度量的方法体系主要包括 5个方面:1. 项目度量,目的在于度量项目规模、成本、进度、顾客满意度等,辅助项目管理进行项目控制; 2. 规模度量,主要依靠经验和经验的模型,是决定项目成败的重要原因之一,是估算工作量、成本预算及策划项目进度的基础; 3. 成本度量, 4。产品度量,实质上是软件质量的度量,软件的质量由一系列质量要素组成,每个质量要素又由一些衡量标准组成,主要肚量方法是McCabe 复杂性度量法; 5,过程度量,对软件开发过程的个各方面进行度量,目的在于预测过程的未来属性,减少结果的偏差,主要包括成熟度度量(例如 CMMI, GJB5000A、管理度量(主要包括里程碑管理、风险度量等项目管理度量,审查度量、质量保证度量等质量管理度量,变更控制、版本管理度量等配置管理度量、生命周期度量三个大的方面。 不同层次的人员对软件度量有不同的需求。高级管理人员,如 CEO 、 COO ,关注点在上市时间、客户满意度、费用的节省等商业策略的组成部分上;中级管理层,如部门经理、总监等,则主要关注生产力、成本控制、效率等,他们更多的是着眼于
软件测试填空题
1、软件质量工程包括软件质量保证、软件质量规划和软件质量控制三大方面。 2、McCall模型产品修改纬度的质量因素有可维护性、可测试性、灵活性。 3、面向对象模型不同于其他模型的主要特征是组件的密集重用。 4、有两种同行评审方法学：审查和走查。 5、RMA可以划分成三组类别内部风险管理措施，分包风险管理措施，顾客风险管理措施 6、支持性质量手段有模板和检查表。 7、依据软件系统的生命周期和其他阶段，软件质量度量划分为软件过程度量和软件产品度量。 8、软件配置发布的版本有基线版本、中间版本、修订版本。 9、SQA标准被划分成软件质量管理标准和软件项目过程标准两类。 10、软件缺陷的固有特征有软件缺陷的固有性、软件缺陷的敏感性、软件缺陷的感染性。 11、McCall模型划分了软件运行、软件转移、软件修改三个纬度的11个软件质量因素。 12、螺旋模型任何一次迭代都可划分为制定计划、风险分析和化解、工程和顾客评估四个项限。 13、依据合同评审的目标对合同评审主题进行分类为建议草案评审主题和合同草案评审主题两种类型。 14、典型的版本方针包括严格-单一活动版本方针、多版本方针。 15、软件对属于各种质量因素的需求的符合性是由软件质量度量来测量的。 16、CAPA过程的成功运行包含如下活动：信息收集、信息分析、解决方案和改进方法的建立、改进方法的执行、跟踪。 17、常见的软件配置演化模型有线性演化模型和树演化模型。 18、软件更改的质量保证工作需要每个更改的SCI的质量保证和整个新软件系统版本的质量保证两个级别的活动。 19、从内容和重点上我们可以把质量管理标准划分成认证标准和评估标准两种类型。 20、测试人员、 SQA单位是SQA专职人员。 21、CMM内容包含初始级、可重复级、已定义级、已管理级和可优化级五个等级。 22、软件质量保证的目标包括面向产品的软件开发和面向过程的软件维护两大方面。 23、开发生命周期阶段SQA部件可以划分成三类：评审、专家观点、软件测试、软件维护SQA部件和由第三方/分包商使用的SQA部件。 24、版本方针和更改方针是维护方针的主要组成。 25、外部参与方可被分类为分包商、COTS软件和重用软件模块的供货
CMMI5文档之度量与分析过程
度量与分析过程 文档编号：FHI_CMMI_MA_PRS 文档信息：度量与分析过程 文档名称：度量与分析过程 文档类别：CMMI过程 密级：内部秘密 版本信息：1.1 建立日期：2016-1-19 创建人：EPG 批准人：李庆林 批准日期：2016-2-25 存放位置：集成公司组织资产库/组织标准过程 编辑软件：Microsoft Office 2003 中文版
文档修订记录
目录 1.简介 (4) 1.1.目的 (4) 1.2.适用范围 (4) 1.3.引用文件 (4) 1.4.术语表 (4) 1.5.角色与职责 (4) 1.6.参考资料 (4) 2.工作过程概述 (4) 2.1.过程概述 (4) 2.2.过程结构描述 (5) 3.工作过程描述 (5) 3.1.定义度量与分析规格说明 (5) 3.2.实施项目度量与分析活动，并提供相应的结果 (7) 3.3.实施公司度量与分析活动，并提供相应的结果 (7) 4.支持文件 (10)
1.简介 1.1.目的 开发和维持软件过程的度量能力，以便支持商业目标和管理信息的需要。 1.2.适用范围 项目和公司度量与分析工作。 1.3.引用文件 ●《项目策划过程》 1.4.术语表 测量（Measure）：是对一个项目或过程的某个特性（例如：规模、工作量、复杂性和缺陷）采 度量（Measurement）：是对一个项目或过程具有的某个特性的度的一个测量。例如：对产品规 分析（Analysis）：是整理、比较和解析度量结果并形成报告的行为。例如：对产品规模与工作 1.5.角色与职责 ●Goal-Driven Software Measurement–A Guidebook [SEI-HB02] 2.工作过程概述 2.1.过程概述 度量与分析过程的功能是从各种工程和管理过程中收集和分析度量数据并为相关的干系人报告度量结果，提供用于监控和改进项目过程和产品质量的管理信息。 度量与分析过程包括下列活动： ●定义度量与分析规格说明； ●实施项目度量与分析活动，并提供相应的结果；
金融风险度量的传统方法
第五章 金融风险度量的传统方法 第一节 金融风险度量的传统方法 一、用价差率来衡量风险 价差率是用来测算单个证券投资风险最简单的方法，其计算公式如下： 价差率＝2╳(最高价－最低价)/(最高价＋最低价)╳100% 上式中的最高价、最低价是指该证券在相应各期限(如年)的最高价和最低价，价差率法的实质是直接将证券的可能波动幅度作为衡量风险的指标。 用价差率来衡量证券的波动幅度和风险，计算简单方便，意义清晰直观；价差率越大，意味着股票的风险越大，反之，则股票的风险越小。而且，可以根据具体情况和需要，采取不同的期限，如年、月、周等来计算价差率。不过，由于用价差率来测量风险时所包含的内容过于狭窄，其精确度和适用范围非常有限。 二、灵敏度分析与β系数法 灵敏度(Sentivity)是收益的方差与产生这一方差的某一随机变量(如利率、汇率等)的方差之比，它是两个方差的比值。设以V 表示收益，χ表示影响收益的市场随机变量，S 表示收益V 对χ的灵敏度，则： V S χ ?=? 或者以两方差的百分比的比值表示为： //V V S χχ ?=? 如某一债券价格对利率的敏感度为5，则它意味着1%的利率方差将产生5%的债券收益方差。若债券价值为10000，则其价值变动的方差为500。 如果某投资组合的收益或价值受到几个市场随机变量的影响，那么该投资组合的风险就需要由这几个灵敏度组成的灵敏度变量来描绘。例如，某证券投资组合的市场价值依赖于各有关货币的利率、汇率、证券价格指数。这时，需将投资组合价值对这些变量的灵敏度都计算出来，但不能将它们直接相加。因为那样意味着各随机变量将在同一时间以给定的幅度变动，从而会夸大风险。
软件开发度量及考核方法精修订
软件开发度量及考核方 法 集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
本人觉得如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。虽然目前很多公司有这方面的绩效考核，但是大多数没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。以下文档是本人根据以前经验和相关的资料所编写的度量方法和考核方法，希望能对公司改善考核制度有用。由于时间有限，有不足之处，请各位仁兄多提意见，谢谢！ 1 目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 2 软件项包括 1）技术文档：参照公司"软件工程产品集"，所确定的配置项；主要包括：可行性分析报告、需求分析报告、软件功能规格说明、开发计划、质量计划、系统设计报告、测试文档、技术报告、用户手册、总结报告等； 2）计算机程序。 3 度量数据的来源 1）项目计划； 2）评审报告； 3）测试报告； 4）问题报告； 5）软件维护记录； 4 质量度量 度量指标 主要根据各类软件项检查表的检查指标来确定，例如，软件需求规格说明书检查表（见附录1），有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。 质量等级 1）软件项的质量等级的确定根据度量综合指标进行。 2）度量综合指标计算公式为：Total = ∑QiMi。 3）其中i=1,2,...n代表指标数量； 4）Q代表度量的指标； 5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。 度量指标权重系数表： 序号指标权重 1 指标1 权数1 2 指标2 权数2 3 指标3 权数3 4 指标4 权数4 5 指标5 权数5 加权平均分 6）质量评价：一般地，根据度量综合指标值，有以下评分标准。 质量评价计分标准表 序号得分质量评价 1 ～优质
软件测试度量(精华)
软件测试度量(精华) 转至https://www.360docs.net/doc/b65418136.html, 摘要： 任何过程的有效管理需要量化、测量和建模。软件度量为开发和软件过程模型的验证提供量化方法。度量帮助组织获得继续提高生产率、减少错误和提高过程接受率、产品、服务以及达到最终目标的信息。 这份白皮书发表了度量生命周期、各种软件测试度量元、度量元元素、过程评估以及达到理想的结果。 一、业务需要 在技术方面日益增加的竞争和飞跃，迫使公司采取创新的方法来评估自己的过程、产品和服务。这种评估将帮助他们改善业务，使他们能够取得成功，并且获得更多利益和较高的市场占有率。 度量是评估的基石也是任何业务改进的基础。 二、软件度量 度量是标准度量单位的量化结果。对于评估软件过程、产品以及服务使用的度量被称作软件度量。 Paul Goodman给出的软件度量定义： 软件度量是一中度量技术，这种技术应用在过程、产品和服务中用来支撑工程和管理信息，以及支持过程、产品以及服务的信息上的改进，如果需要的话。 三、度量的重要性 ● 度量是用来提高质量、产品生产力以及服务，从而达到客户满意度。 ● 对于管理组织很容易分析数据并且深入下去，如果需要的话。 ● 当过程不受控时有不同的度量方式作为监控者。
● 度量提供当前过程改进。 四、记忆要点 ● 度量那些可以收集的必须使用的准确以及完整数据。 ● 度量必须很容易解释以及评估。 ● 度量多样化使度量基准形式可以从组织到组织，也可以是个人到个人。 五、度量生命周期 建立度量时涉及的过程： 六、软件测试度量类型 基于测试执行的不同类型，下面就是软件测试度量的类型： 1、手工测试度量 2、性能测试度量 3、自动化测试度量 下面的图表展示了不同的软件测试度量
软件项目量化管理方法
软件项目量化管理方法 摘要：本文在对软件企业量化管理应用常见问题分析的基础上，以解决可操作性、可比性等问题为着眼点，识别出了量化管理中必须明确的四要素，表述了企业在量化四要素上采用的常见做法。 本文采用80/20原则，说明了企业在识别度量对象时应避免的问题；采用持续改进的理论，说明了企业在量化管理应遵循的客观规律。在结合平衡记分卡与目标驱动组合式的量化管理方法理论基础上，提出了软件企业的量化管理的具体应用步骤。 关键词：量化管理四要素80/20原则持续改进GQ(I)M 1. 引言 如今，很多国内软件企业选择采用能力成熟度系列模型（Capa bility Maturity Model, CMM）或其它模型来建立本企业的软件过程规范，欲通过提升软件过程的能力达到提高产品质量、降低开发风险、减少开发成本、保证产品按时交付等目的。将软件过程规范的一个目的就是使软件过程可视化，这个可视化则要求了对软件过程的量化；而产品质量是否提高、开发风险是否降低、开发成本是否减少、项目延期是否缩短，对这些问题的回答则要求了对软件项目的量化；软件过程改进与量化管理息息相关。
不少企业在将识别出的量化管理方法应用于软件项目管理过程时，发现不少问题。最为常见的是： 量化工作的可操作性不强，如：部分量化数据难以收集、难以统计投入的成本没有得到预期的产出。如：量化工作投入了成本，但形成的量化结果参考价值不高提供给管理层用于决策的支持数据也不够，数据缺乏可比性量化结果不是管理层所关心的，达不到管理层预期的过程可视化程度 针对此类问题，本文识别出了在量化管理中必须要考虑的四个方面，即：量化四要素，并从量化四要素对量化管理方法进行了分析，建议了软件企业采用的量化管理方法。 2. 量化四要素 “只有通过对产品、过程的度量，才能描述、评价、提高产品与过程”。 笔者认为，要度量，就要明确度量的对象；要度量对象，就要明确标识度量对象的计量单位；要产生度量结果，就要明确度量方法，包括度量技术和数据收集的方法；要评价度量对象，就要明确用于比对的基准指标，即表征度量对象目前情况的标尺，通过该标尺与度量结果的比对，得出对度量对象的评价。而度量对象（Object）、计量单位（Unit）、度量方法（Method）、基准指标（Benchmark），这就是笔者所说的量化四要素。
测试质量衡量标准
测试质量衡量标准 质量衡量标准(标尺) 可清晰量化的衡量产品质量 测试覆盖率-代码块覆盖,功能覆盖,用例覆盖....这么多覆盖率,每个覆盖率,合理的目标是多少?50%?80%100% 按照找到的缺陷数目,多少是被用户找到的,多少是被内部非测试团队找到的,多少是被测试团队找到的,以此为衡量质量的标尺之一? 重复发生的回归性缺陷数目 补丁和Service package数量,来衡量质量 我们有这么多可以用来衡量质量的标准,那么,哪些应该是核心的标准,最重要的普遍标准.怎么把各个标准和质量关联上? 制定发布的质量指标,怎样才是正确的指标,可以指导我们决定发布还是延迟发布产品直到我们达到该指标. 怎么定义测试效率?包括怎么衡量s变化对测试的影响.. 怎么定义测试"完成"了? 复杂领域产品测试: 音频和视频质量测试 "看起来效果对吗?" "听起来效果对吗?" 效果"好"吗? 各种主观类型的测试判断 测试工具对系统本身的影响(测不准原理?): 性能测试工具本身对机器性能的影响所导致的测不准效果. 如何确定一个软件的测试结束点 在软件消亡之前，如果没有测试的结束点，那么软件测试就永无休止，永远不可能结束。软件测试的结束点，要依据自己公司具体情况来制定，不能一概而论！个人认为测试结束点由以下几个条件决定： 1．基于“测试阶段”的原则：
每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段，我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后，再进行后面一个阶段的测试。举个例子来说：单元测试，我们要求测试结束点必须满足“核心代码100％经过Code Review”、“功能覆盖率达到100％”、“代码行覆盖率不低于80％”、“不存在A、B类缺陷”、“所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准，当然也是如此。 2．基于“测试用例”的原则： 测试设计人员设计测试用例，并请项目组成员参与评审，测试用例一旦评审通过，后面测试时，就可以作为测试结束的一个参考标准。比如说在测试过程中，如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在功能测试用例通过率达到100%，非功能性测试用例达到95%以上，允许正常结束测试。但是使用该原则作为测试结束点时，把握好测试用例的质量，非常关键。 3．基于“缺陷收敛趋势”的原则： 软件测试的生命周期中随着测试时间的推移，测试发现的缺陷图线，首先成逐渐上升趋 势，然后测试到一定阶段，缺陷又成下降趋势，直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向，来定测试是否可以结束，这也是一个判定标准。 4．基于“缺陷修复率”的原则： 软件缺陷在测试生命周期中我们分成几个严重等级，它们分别是：严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时，严重错误和主要错误的缺陷修复率必须达到100%，不允许存在功能性的错误；次要错误和一般错误的缺陷修复率必须达到85%以上，允许存在少量功能缺陷，后面版本解决；对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题，可以暂时不用修改。 5．基于“验收测试”的原则： 很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。如果通过用户的测试验收，就可以立即终止测试部门的测试；如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。
如何进行有效的软件度量
- 如何进行有效的软件度量 什么是软件度量 软件度量（Software Measurement）是通过各种不同的量度(metric)对软件生命周期中的各个元素进行度量(Measure)，它能够为项目管理者提供有关项目的各种重要信息，同时也是进行大多评估活动的基础。 "软件度量"是一个包含很多完全不同的活动的术语。它主要包括：费用和工作量估计模型和度量、生产率度量模型和标准、质量控制和保证、数据收集、质量模型和度量、可靠性模型、性能评价和模型、算法/计算复杂性度量、结构和复杂性度量、GQM法(Goal/Question/Metric)、其他等。 通常度量程序是由一些软件工程组在组织中进行实施，而这种用于量化软件过程的决策手段实际上能为所有涉及软件的人或部门带来好处： 1.项目经理得益于在计划及控制软件项目时作出相关决策； 2.项目成员能聚焦于工作的改进； 3.软件配置管理组能关注于产品的完整性； 4.软件质量保证组则能专注于过程的保证； 5.当然用户则关于软件产品的最终使用； 6.除此以外，其他涉及并关心软件过程及产品的职能部门都能以此作出相关决策。为什么需要软件度量 在软件开发中，软件度量的根本目的是为了管理的需要，利用度量来改进软件过程。 在软件开发的历史中，我们可以意识到，在60年代末期的大型软件所面临的软件危机反映了软件开发中管理的重要性。而对于管理层人员来说：没有对软件过程的可见度就无法管理;而没有对见到的事物有适当的度量或适当的准则去判断、评估和决策，也无法进行优秀的管理。 我们说软件工程的方法论主要在提供可见度方面下工夫。但仅仅是方法论的提高并不能使其成为工程学科，这就需要使用度量。 度量是一种可用于决策的可比较的对象。度量已知的事物是为了进行跟踪和评估。对于未知的事物，度量则用于预测。 事实上现在在软件工程的主流里度量却被忽略了。现在的情况是： ■当我们在设计和开发软件产品的时候，我们并未能制定出度量的目标。例如：我们保证说我们将使用户界面友好、可靠、易于维护;而并未使用度量的术语来详细说明它们的具体含义。Gilb曾经说过：所谓模糊目标定理，就是没有明确目标的项目将不能明确地达到它的目标。 ■我们未能对构成软件项目实际费用的各个不同的部分进行有效的度量。譬如：通常我们并不知道，和测试阶段相比，设计阶段花费时间多大。 ■我们并未试图使我们开发的产品的各种质量合格。因此我们未能使用术语(如：在一段时间里使用故障的可能性、把产品安装到新环境中需花费的工作量等)向潜在的用户说明产品的可靠性很高。 ■我们总是试图说服自己使用另一种新的革新的开发技术和方法进行软件开发 事实上，我们在软件度量方面做的工作很少很少，而且所作的度量方面的工作也与一般科学意义上的度量相分离。我们经常会看到诸如此类的话："软件的费用有80%花费在维护上。"或"软件每一千行程序中平均有55个Bugs。"。但是这些话并没有告诉我们这样的结果是怎样产生的、试验是怎样设计、执行的、度量的是那个实体、及错误的框架是什么等等。没有这些东西，我们就不能在我们自己的环境中客观地进行反复度量，重现度量的结果
金融风险度量方法研究
龙源期刊网 https://www.360docs.net/doc/b65418136.html, 金融风险度量方法研究 作者：蒋彦平 来源：《现代经济信息》2013年第15期 摘要：随着经济全球化进程的逐渐发展，金融市场在这一背景之下，大大小小不同的波动更加容易出现。其中金融波动对金融市场的稳定性造成了一定的影响，导致金融风险的存在也日益严重。在美国经济危机爆发，对全球经济造成了严重的影响之后，更加提升了人们对金融风险的重视。那么为了能够对金融风险进行有效的预防，就必须要找到一个科学合理的风险度量方法。下面本文就对金融风险度量方法进行详细的分析。 关键词：金融；风险；度量方法 中图分类号：F832.3 文献标识码：A 文章编号：1001-828X（2013）08-0-01 金融风险的出现不但会对金融机构的正常运行产生一定的影响，甚至还会导致连锁反应的出现，从而造成全球经济动荡。各金融机构为了能够对金融风险进行有效的控制，均加强了对其科学合理风险度量方法的研究，以此确保可以对金融风险进行准确的评估，提高金融风险控制力度[1]。其中由于各金融风险之间也具有一定的差异性，因此其度量方法也有所不同，下 面本文就对目前金融市场，最常用的三种进行探讨。 一、金融风险方差度量方法 在Markowitz1952年所发表的《资产选择》中，首次对金融理论进行了定量化的研究，那么Markowitz也就成为了第一个对金融市场风险，采用数量方法进行度量的人。其中他的资产组合理论是在规范分析的基础上，对人们在进行资产选择时，怎样才能够对金融风险进行有效避免，从而获取最大化的经济效益的方法进行的探讨。其中一开始市场风险的原型就是在资产组合理论中出现的，Markowitz曾把它称为是一种具备不确定性的资产收益。Markowitz对于 这一资产收益不确定性的度量，采用的是统计学中的方差或者标准差，那么这一方法也就成为了金融风险度量中的最早方法，金融风险大小也就第一次被Markowitz采用具体的数量进行的刻画。方差这一金融风险度量方法不但具有概念明确、统计性好以及容易理解的优点，同时在收益率对正态分布假设条件服从的条件下，可以把组合方差分别称为多个单个的资产收益率方差和协议差。金融风险的方差度量方法，具有良好的适用性和简便性，因此到目前为止，其不但在金融风险度量中使用范围最广，使用最广泛，同时也是之中影响最大的度量方法[2]。但 随着人们对金融风险本质认识的深入，这一度量方法所展示出来的弊端也越来越多，其中方差方法本身的定义就和风险的原始含义具有偏差，对于真实风险的大小不能够进行度量，其虽然可以帮助投资者规避一定的风险，但是也具有使其失去更多收益机会的可能。另外方差方法的假设具有一定的严格性，具有比较繁重的计算任务，因此也就迫使人们不断的对新的金融风险度量方法进行探寻，以能够对方差方法中所具有的弊端进行消除，从而提高金融风险度量的科学性、合理性和准确性[3]。
软件规模度量方法介绍
软件规模度量方法介绍 作者 学号 班级 摘要软件规模度量是一项困难度很高的任务。文章介绍了国际上广泛采用的一种软件规模度量的办法———IFPU G功能点度量方法，说明了该方法的基本原理和具体计算方法，并分析了它的优缺点。同时对国际上其他几个颇有影响的软件规模度量方法，也作了简要的介绍。 关键词软件项目项目计划进度进度计划 1、引言 软件度量是指对软件规模、软件项目工作量、软件生产率、软件项目开发成本、软件质量、软件的上线日期等事项进行量化，使复杂的软件过程通过数字的描述让相关人员能够正确理解和管理。软件度量满足了三方面的需要：首先是满足了项目管理的需要。项目经理根据软件度量的数据可以对有关资源进行合理部署和分配，有效地对项目的进度和执行情况进行监控，确定软件产品是否符合质量的要求等。其次，满足了组织的需要。依照度量的数据，组织可以清楚地了解开发的效率和质量的总体水平，从而可以更好地进行产品组合、判定资金的投向，策划、管理或验证软件开发的活动。第三是满足了用户的需要。用户可以根据度量的数据比较正确地判定投入的资金，项目交付的合理期限以及判定递交项目的质量等。因此，研究软件的度量有着十分重要的社会意义和应用意义。在软件度量的课题中，软件规模度量是其他软件度量工作的基础与关键。要对软件的规模进行度量，首先就要求确定一种度量的单位。用软件的源代码行数作为软件规模的度量是一个比较传统的度量方法。它的度量单位是K LO C（千条源代码）。例如，一个软件有15000 条源代码行数时，它的规模就用15K LO C 来表示。这种方法的优点是，比较直接、简单。但是，它的结果与使用的程序语言密切相关，尤其在开发人员大量使用第四代语言以上的工具进行 软件开发时，用K LO C 描述一个软件的规模就显得非常不准确。而且，用这种方法只能在软件开发完成之后才能进行源代码行数的准确度量。现在，除了套用某些经验公式进行软件工作量的估算时 人们还用到这种度量方法外，K LO C 几乎不再被使用。因此，本文着重介绍国际上比较流行的IFPU G 功能点度量方法，同时，也简要地介绍其他两个国际上比较有影响的软件规模度量方法。 2、FPUG 功能点介绍法 2.1功能点分析法的基本原理 功能点分析是把应用系统按组件进行分解，并对每类组件以IFPU G 定义的功能点为度量单位进行计算，从而得到反映整个应用系统规模的功能点数。功能点分析从用户对应用系统功能性需求出发，对应用系统两类功能性需求进行分析：一类是数据功能性需求，另一类为交易功能性需求。数据功能性需求又分为：内部逻辑文件（ILF：Internal Logical Files）和外部接口文件（EIF：External Interface Files）两类。交易功能性需求则分为：外部输入（EI：External Inputs），外部输出（EO ：ExternalO utputs），外部查询（EQ ：External Inquiry）三类。所以，应用系统一共可以按五类
基于CMMI的软件过程度量
摘要：CMMI为软件产品及软件过程提供了一套定量的表示和分析，即软件度量的模型。有效的软件度量过程能促进组织的软件过程能力的改进。文章结合国内应用特点，介绍了基于CMMI的多层架构软件产品的度量模型，并着重讨论了基于CMMI的软件过程度量，总结了软件过程度量的工作方法和思路，提出了解决国内软件度量的一般性方法，为软件过程改进提供了可行的方法和实践。 关键词：CMMI；软件度量；软件过程能力；度量项；门限值 0引言 软件度量的目的是为项目管理提供项目的执行情况的充分可见性，并使项目管理者了解项目实际进展与项目计划之间的偏差，以便采取纠正行动，保证项目的顺利进行。有效的软件度量过程促进组织的软件过程能力的改进。软件度量是软件特性的定量表示和分析方法；软件度量可分为软件产品度量和软件过程度量两类。软件产品度量(定量表示和分析软件产品特性)是独立于产品生产过程的度量；软件过程度量(定量表示和分析软件过程特性)是为管理者提供产品生产过程的状态信息和指导依据。 软件产品度量的要素为质量要素、评价准则、度量元。这里软件过程度量主要通过需求度量、规模度量、进度度量、工作量度量、风险管理度量、质量保证度量来分析。 1三层架构软件产品度量 1．1质量要素 软件质量可分解成六个要素，这六个要素是软件的基本特征。功能性：软件所实现的功能满足用户需求的程度；可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度；易用性：对于一个软件，用户学习、操作、准备输入和理解输出时所做努力的程度；效率：在指定的条件下，软件实现某种功能使用计算机资源(包括时间)的有效程度；可维修性：为了满足用户需求、环境改变或发生软件错误时，对软件进行相应修改所需的努力程度；可移植性：软件从一个计算机系统或环境转移到另一个计算机系统或环境的难易程度。 1．2评价准则 评价准则包括：精确性、健壮性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、产品文件完备性。 1．3度量元 根据软件的需求分析、概要设计、详细设计、实现、组装测试、确认测试和维护与使用七个阶段，制定针对每一个阶段的度量元。 2基于CMMI软件过程度量 从软件企业的观点出发，软件度量(software Measurement)是通过各种不同的量度对软件生命周期中的各个元素进行度量(Measure)，为项目管理者提供有关项目的各种重要信息，也是进行软件评估活动的基础。 Carnegie Mellon大学的SEI提出了以下的一个软件度量过程体系结构图：
金融风险度量方法选择及适用性分析
金融风险度量方法选择及适用性分析 在很长时期内风险价值模型（Value at Risk，以下简称VaR）都作为首选来度量风险，然而其理论和应用都存在缺陷。VaR并没有考虑潜在的尾部风险，而且不满足一致性风险度量的公理条件，即VaR不是一个理想的风险度量。本文从理论上分析了VaR模型存在的缺陷，并介绍其他风险度量模型，研究其特性，最后在此基础上提出金融风险度量选择的依据。 关键词：风险价值一致性风险度量期望短缺谱风险度量扭曲风险度量 回顾金融风险管理理论的发展史，20世纪70年代是现代金融风险管理发展的重要年代。布雷顿森林体系破产之后，利率、汇率等市场风险问题在金融机构的风险管理中日益凸显。而1973年4月，芝加哥期权交易所（CBOE）的正式运营以及著名的布莱克-舒尔茨期权定价模型的发表标志着现代金融风险管理时代的到来。20世纪90年代，以金融工程为代表的现代金融风险管理技术发展迅速，市场风险和信用风险的量化管理也得到了很大的发展。然而长期资本管理公司（LTCM）的破产为金融工程的应用提出了警示。金融工程的发展使得大量的数理统计模型在金融风险管理中获得应用，这其中包括著名的VaR模型。 我国金融市场是一个发展中的新兴市场，金融风险管理的手段还比较落后，主要以定性分析为主，重在事后分析和评估，缺少事前风险防范和控制。随着我国的金融改革的发展和金融市场的进一步开放，金融监管的原则与风险管理的技术必须符合国际惯例要求。 VaR模型的产生及其局限性 风险管理的基础和核心是对风险的定量分析和评估，即风险度量。传统的风险度量方法如Beta、Delta、久期和凸性等仅适用于特定的金融工具或领域，难以全面反映风险覆盖情况。在这一背景下，1993年G30小组首先提出风险价值（Value at Risk）的概念，VaR模型旨在估计给定投资工具或组合在未来资产价格波动下可能的潜在损失。这一指标最大的优点是能够测量由不同市场因子导致的风险，以及不同市场的总风险，能够较为准确地测量不同风险因子及其相互作用而产生的损失，能够适应金融市场发展的动态性、复杂性和全球化的趋势。 然而，VaR度量的是正常市场情况下的市场风险，在现实中，金融市场出现剧烈波动的极端市场情形大量存在，即VaR并没有考虑潜在的极端市场情形。对VaR实践的评估以及对风险度量的进一步研究指出VaR并非一个一致性风险度量，其不满足次可加性的公理条件，从而无法进行风险分散。 正是由于VaR还存在着理论与应用上的缺陷，推动了风险度量的进一步发展。在VaR的基础上许多研究者提出了风险度量的其他方法。Acerbi and Tasche （2002）提出期望尾部损失ES（Expected Shortfall，以下简称ES），Wang（1996）提出扭曲风险度量的概念，Acerbi（2002，2004）将经济学的风险偏好理论引入风险度量中，提出了谱风险度量，从而使风险管理的实践者有了更多的选择。 基于分位数回归的风险度量 （一）风险价值VaR VaR的含义是“风险中的价值”，JP Morgan将VaR看作既定头寸冲消或重估前可能发生的市场价值的最大损失的估计值。而VaR比较权威的定义由Jorion （1997）提出，将其定义为给定置信水平下，风险资产在持有期内可能遭受的最
软件开发度量及考核方法
软件开发度量及考核方法 一、引言 如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。虽然目前很多公司有这方面的绩效考核，但是由于软件开发行业的特殊性，大多数公司没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。所以根据以前经验和相关的资料编写了适用于本部门的度量和考核方法。该考核方法是技术支持部软件开发人员和测试人员的试行版本。 二、目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 三、考核实施办法 1、定义 1.1 、软件项包括 1）、技术文档："软件工程产品集"所确定的配置项。主要包括：用户需求文档、需求分析文档、概要设计文档、详细设计文档、开发计划、测试文档、用户手册、总结报告等。 2）、计算机程序。 1.2 、度量数据的来源 1）、项目计划：过程度量中及时度考核数据的主要依据。 2）、测试文档：计算机程序质量考核数据主要依据。 3）、软件维护记录：主要是指软件产品投入用户使用后产生的软件维护记录。
2、质量度量 2.1度量指标 主要根据各类软件项检查表的检查指标来确定。例如，详细设计说明书检查表有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。（本文末尾附了各工作阶段的考核检查指标表） 2.2质量等级 1）软件项的质量等级的确定根据度量综合指标进行。 2）度量综合指标计算公式为： Total =刀QiMi。 3）其中i=1,2,...n 代表指标数量； 4）Q代表度量的指标； 5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。
软件项目或软件产品的度量(doc 17页)
度量
沈阳东大阿尔派软件股份有限公司（版权所有，翻版必究）
文件修改控制
目录 1. 目的 2. 适用范围 3. 职责 3.1 项目管理部门 3.2 测试部门 4. 术语和缩略语 5. 工作程序 5.1 产品度量数据的来源 5.2 产品度量的指标 5.3 软件的质量等级 5.4 产品度量指标的获得方法 5.5 过程度量 6. 引用文件 6.1 NP504100《项目策划》 6.2 NP505100《质量策划》 7. 质量记录 7.1 NR604100A“产品度量表” 7.2 NR604100B“过程度量表”
1.目的 对软件开发的过程质量及最终产品的质量进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件的质量水平。 2.适用范围 适用于所有软件项目和/或软件产品的产品度量和过程度量。 3.职责 3.1 项目管理部门：负责对软件开发的过程质量进行度量，记录度量的结果。 3.2 测试部门：负责对软件产品的质量进行度量，记录度量的结果。 4. 术语和缩略语 本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。 5. 工作程序 5.1 产品度量数据的来源 1)系统设计报告； 2)测试报告和测试总结报告； 3)用户对软件项目或软件产品的评价； 4)产品维护记录。 5.2 产品度量的指标 1)功能性：指软件是否完成了设计的功能； 2)可靠性：指软件是否健壮，是否存在运行、计算等错误；
3)友好性：指软件是否容易使用、界面一致、在线帮助齐全； 4)效率：指软件运行的快捷性和空间利用率； 5)可维护性：指软件的设计、制造文档是否齐全，编码是否具备可读性、可理 解性、可改性与可测试性； 6)可移植性：指软件是否能在不同环境下运行，若不能直接运行，修改量是否 很大； 7)综合评价：指根据上述六项指标选择合适的权重计算出的产品综合评价指标。 5.3软件的质量等级 5.3.1 软件的质量等级的确定根据度量综合指标进行。 5.3.2 度量综合指标计算公式为： 综合评价指标= 功能性Q1M1+ 可靠性Q2M2+友好性Q3M3+效率Q4M4+可维 护性Q5M5+可移植性Q6M6 使用符号代表：total=∑QiMi。其中i=1,2,...6，Q代表度量的指标，M代表度量 的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系 数由质量保证部根据开发的不同着重点给出。 5.3.3 质量评价 一般地，根据度量综合指标值，有以下评分标准：
软件测试过程的度量
软件测试过程的度量 1）测试度量的作用 A:为制定测试计划时提供依据 需要多长时间?需要什么物质条件？需要多少人，什么素质的人？在规定的时间内能完成到什么程度？ 哪些模块及功能需要重点关注？测试工作量占整个项目的比例？测试结束后我们能达到什么样的目标？等等 ( 这些数据是我们在项目启动过程中，制定测试计划，尤其在规划资源的过程中，一些必要的参考值。不同项目可能会有其特殊性，但从总体上看，他们还是有一些规律可寻的，过去的经验数据可以作为一个大概估算，如果项目经验丰富，那么可以从历史数据中找出和新项目类似的情况，以能更为准确的完成计划。) B：提高测试流程可控性 提高测试效率和质量 提高测试人员的成就感 2)在测试哪个过程做度量 （产品早期的市场评估、测试策略分析、可测试性需求分析、测试工具分析、用例设计阶段、执行阶段和FOA 阶段） 我们需要在测试的几个关键阶段做度量，它们分别是：用例设计阶段、执行阶段和FOA 阶段。测试用例设计阶段包括测试方案的最终确定、测试工具的设计、测试用例编写等，测试执行阶段很明显，即我们测试的各个过程，如集成测试、系统测试、性能测试、回归测试等，也包括开发人员完成的单元测试的度量工作。FOA 阶段是检验测试质量的第一步，通过FOA 我们可以获得很多为产品质量做贡献的度量，这也是体现测试价值的度量。看起来几乎包括了测试过程的全部。其实这里包括的只是测试的具体工作阶段。 3）测试度量的内容 两种度量类型： A：项目度量：规模、测试工作量、测试进度、测试生产率 B：质量度量：缺陷率（阶段）、缺陷排除率、可靠性等 四个基本度量项：规模、工作量、进度、缺陷 4) 测试用例设计阶段的度量 A：规模：测试方案数量、测试用例数量、测试工具设计数量、测试用例/人月 B：工作量：文档的草稿编写工作量、评审前阅读工作量、评审工作量、修改工作量 C：进度：每件具体工作的计划开始结束时间、实际开始结束时间、计划工时数、实际工时数、计划完成率 D：缺陷：评审过程中出现的错误数量、缺陷数量，级别 5）测试执行阶段的度量： ? 测试用例执行率? 测试用例通过率 ? 测试用例问题发现率? BUG数量 ? BUG级别统计? BUG分布统计（模块） ? BUG分布统计（阶段）? BUG密度 ? BUG关闭率? 人均BUG发现效率 ? 测试用例执行工作量项目? 回归测试执行工作量
金融风险的概率调整度量方法及应用
财政金融投资 [收稿日期]2005-05-24 [作者简介]石媛昌(1974-),女,安徽合肥人,中国农业大学理学院讲师,首都经济贸易大学博士研究生,研究方向是金 融工程;韩立岩(1955-),男,北京人,北京航空航天大学经管学院博士生导师,教授,研究方向是金融工程。 金融风险的概率调整度量方法及应用 石媛昌1,韩立岩2 (1.中国农业大学理学院,北京100083;2.北京航空航天大学经济管理学院,北京100083) [摘 要]基于概率调整的金融风险度量方法是从保险业中针对保险风险发展起来的一种方法。它通过对风险的真实概率分布进行修正,来给予高风险事件更大的权重,也就是说,投资者通过调整对右侧尾部风险的主观认识来表明自己对风险的回避程度,最终得到对风险的评价。文章在Choquet 积分这一框架下对VaR 和T CE 风险度量的概率调整表示方法以及一些新的风险度量方法进行了归纳和总结,并通过理论和数值分析对这些不同风险度量的特征和相互关系进行了研究。 [关键词]风险度量; 概率调整函数; VaR ; G ARCH [中图分类号]F830 [文献标识码]A [文章编号]1007-9556(2005)04-0096-03 Measurement of Financial Risk :a Probability -readjustment -based Method SHI Y uan -chang 1,HAN Li -yan 2 (1.School of Science ,China Agricultural University ,Beijing 100083; 2.School of Economic Management ,Beijing University of Aeronautics and Astronautics ,Beijing 100083,China ) Abstract :In the framew ork of Choquet integral ,the paper makes a summary of the probability readjustment method applied to the risk measurement and other new measuring methods.I t als o studies the features and interrelation of these methods through theoretical and numerical analysis. K ey Words :risk measurement ;probability readjustment function ;VaR ;G ARCH 一、引言 对风险进行恰当而又准确的度量是进行风险管理和风险控制的前提条件。风险价值(VaR )是当前流行的一种风险度量方法(J.P.M organ (Risk Met 2rics [1]))。VaR 就是指在一定的置信水平下在某一 特定时期内给定的投资组合可能遭受的最大损失。VaR 把资产或投资组合的风险归纳起来用单一的指 标来衡量,是一种易于理解和使用的风险度量。但是,VaR 仍然有许多不尽如人意的地方。Artzner 等人[2][3]提出了风险度量的公理化基础,他们指出,一种合理的风险度量应该满足四个性质:单调性、次可加性、正齐次性和平移不变性,并把满足上述四个性质的风险度量称为一致风险度量。VaR 不是一致风险度量,因为它不满足次可加性,即两种资产组合的VaR 比这两种资产各自的VaR 的和还要大[3],这意 味着资产组合的分散化会使风险增加,也就是说, VaR 对于分散化投资的风险的描述是不恰当的。这使得Artzner 等人建议使用尾部条件期望(T ail C ondi 2tional Expectation ,T CE )作为VaR 的替代品。本文借鉴Wang (1996,1997)[4][5]提出的保险风险定价领域 的一种基于概率调整的风险度量方法,把金融风险 作为调整后概率的期望进行讨论,利用调整概率的Choquet 积分来定义风险度量。在Choquet 积分的框架下,按不同的概率调整方法对风险度量进行分类,介绍了VaR 和T CE 的概率调整函数,以及机会比例(Proportional Hazards ,PH )变换、对偶幂(Dual P ower ,DP )变换等新的风险度量方法,最后,对这些不同的风险度量进行了实证分析,并考察和比较了不同风险度量的特征。 二、基于概率调整的风险度量 设P 为σ代数F 上的概率测度,g :[0,1]→[0,1]为增函数,且有g (0)=0,g (1)=1。则μ=goP ? 69?