工程成本规划与控制课程教案
第十章 工程项目成本风险分析与管理（2学时） 一、本章教学目的 通过本章的学习，让学生了解工程项目成本构成要素的不确定性与风险管理的基本理论，学会工程项目成本风险分析的工具和技术与风险管理的手段和方法，提高风险识别、估计和评价的工程项目风险分析和管理的能力。 二、本章教学重点和难点 本章教学重点和难点是工程项目成本风险分析与管理中的风险识别、估计和评价的技术、手段和方法。 三、本章教学内容 （一）工程成本构成要素不确定性与风险管理 1.工程成本构成要素不确定性分析 （1）工程成本构成要素是随机变量 工程成本构成要素是随机变量，在于工程成本无论采用何种分类标准，其构成要素都要受自然、社会、技术、经济、法律等影响。工程成本是决定建设工程价值的重要因素，最终归为工程量和相关取费标准上，而这两个确定建设工程成本的重要方面受可控和不可控的影响因素非常多，都是随机变量。 工程成本构成要素之所以具有不确定性和随机性特征，在于以下三个原因（图10.1）： 图10.1 工程成本构成要素不确定性的原因 ① 项目环境的不确定性 工程项目的立项、分析、研究、设计和策划都是基于对未来环境（市场、经济、社会、自然等）的预测，是基于正常的或理想的技术、管理和组织。而在具体实施过程中，工程项目所处的环境因素均可能会产生变化，各方面均存在着不确定变动。
②工程行为主体的不确定性 工程行为主体（图10.2）包括政府部门、业主、投资者、项目管理者、承包商、咨询中介等。这些行为主体的资信、技术能力、资金实力、企业经营状况、合同执行、业务流程等差别甚大，彼此间相互作用，因此他们的行为和决策都会影响到工程成本管理 图10.2 工程行为主体不确定性 ③工程成本信息不完备 信息不完备是工程成本不确定性的原因之一，信息获取主体对工程的认识能力，是获取工程成本信息的前提，对信息的获取能力是获取工程信息量的关键，由已知工程信息对未来工程信息判断能力是工程信息加工的必备。工程成本的形成过程中，存在大量的信息采集、加工、推断，导致了工程成本的不确定性因素众多。如图10.3所示“＋”表示正向相关。 （2）工程成本构成要素服从一定概率分布 工程成本构成要素是随机变量，服从概率分布规律，其理论依据是： ①大数定律 大数定律（Law of Large Numbers）是指对大量随机现象中普遍存才的必然性与规律性的抽象化总结，在随机现象的大量重复出现中，往往呈现几乎必然的规律，这类规律就是大数定律。随着研究对象的观察单位数增加到足够量时，研究
软件测试度量(精华) 转至https://www.doczj.com/doc/7e1265455.html, 摘要： 任何过程的有效管理需要量化、测量和建模。软件度量为开发和软件过程模型的验证提供量化方法。度量帮助组织获得继续提高生产率、减少错误和提高过程接受率、产品、服务以及达到最终目标的信息。 这份白皮书发表了度量生命周期、各种软件测试度量元、度量元元素、过程评估以及达到理想的结果。 一、业务需要 在技术方面日益增加的竞争和飞跃，迫使公司采取创新的方法来评估自己的过程、产品和服务。这种评估将帮助他们改善业务，使他们能够取得成功，并且获得更多利益和较高的市场占有率。 度量是评估的基石也是任何业务改进的基础。 二、软件度量 度量是标准度量单位的量化结果。对于评估软件过程、产品以及服务使用的度量被称作软件度量。 Paul Goodman给出的软件度量定义： 软件度量是一中度量技术，这种技术应用在过程、产品和服务中用来支撑工程和管理信息，以及支持过程、产品以及服务的信息上的改进，如果需要的话。 三、度量的重要性 ● 度量是用来提高质量、产品生产力以及服务，从而达到客户满意度。 ● 对于管理组织很容易分析数据并且深入下去，如果需要的话。 ● 当过程不受控时有不同的度量方式作为监控者。
● 度量提供当前过程改进。 四、记忆要点 ● 度量那些可以收集的必须使用的准确以及完整数据。 ● 度量必须很容易解释以及评估。 ● 度量多样化使度量基准形式可以从组织到组织，也可以是个人到个人。 五、度量生命周期 建立度量时涉及的过程： 六、软件测试度量类型 基于测试执行的不同类型，下面就是软件测试度量的类型： 1、手工测试度量 2、性能测试度量 3、自动化测试度量 下面的图表展示了不同的软件测试度量
软件度量总结 这次总结的结构比较简单,就是按照五个章节分别阐述了自己的理解。 一.软件度量的应用范围。 经过这一阶段的学习,我认为想要明白软件度量,首先要分清度量和测量的区别。度量具有前置性,它提供了一种定量研究软件问题的方法;测量具有实时性或后置性,主要集中在给度量提供数据或者处理数据的方法上。由于软件工程强烈的不确定性,使得软件工程的精确测量困难重重,但软件度量主要研究的是可能性的规律,通过概率和统计学的研究,寻找事物内在的规律。其并不具备 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软件和重用软件模块的供货
工程项目风险管理
第十一章项目风险管理 11.1 风险管理概述 工程项目是一种一次性、独特性和不确定性较高的工作，存在着很大的风险性，所以必须开展项目风险管理。 工程项目的实现是一个存在着很大不确定性的过程，因为这一过程是一个复杂的、一次性的、创新的，并涉及到许多关系与变数的过程。工程项目的这些特性造成了在项目的实现过程中存在着各种各样的风险，如果不能很好地管理这些风险将会造成项目的损失，甚至导致项目目标不能实现。 项目风险管理的主要任务是对工程项目实现的过程中的不确定性和风险性事件或问题的管理。 风险概念：是指由于但是者不可预见的因素，使得最终结果与但是者的期望城市较大背离，并存在使当事者蒙受损失的可能性。 项目风险的概念：是指由于项目所处的环境和条件本身的不确定性，和项目业主/顾客、项目组织或项目的某个当事者主观上不能准确预见或控制的因素影响，使项目的最终结果与当事者的期望产生背离，并存在给当事者带来损失的可能性。 11.2 项目风险管理角色描述
工程项目风险管理贯穿于工程项目实现的全过程，对于工程项目的承包方，从准备投标开始直到保修期结束。在整个过程中，因各阶段存在的风险因素不同，风险产生的原因不同，管理的主要责任者、管理方法手段也会有所区别，在项目经理承接该项目之前，风险管理的责任主要集中于企业管理层，并主要是从项目宏观上进行风险管理，而工程项目一旦交由项目经理负责后，项目风险管理的主要责任就落实到项目经理以及项目经理所组建的项目团队。 但无论谁是项目风险管理的主要责任人，对于项目整体，都要贯彻全员风险管理意识。 11.3 项目风险管理流程（见附图11.1） 11.4 风险管理规划（从属于项目管理计划） 11.4.1项目风险管理规划的依据 事业环境因素、组织过程资产、项目范围说明书、项目管理计划书 11.4.2项目风险管理规划的方法 规划会议： 1、参会人员：由项目经理、项目团队成员、厉害相关方和其他人员参与。 2、会议议题：A、确定风险管理活动的基本计划； B、分配风险职责；
软件开发度量及考核方 法 集团标准化工作小组 #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 ～优质
软件过程与软件管理课程复习题 (一)解释相关概念或术语 1)软件工程 ●是指导软件开发和维护的工程类学科，它以计算机科学理论及其他相关学科的理论为指导，采用工程化的概 念、原理、方法和技术，进行软件的开发和维护，并与经过时间证明正确的管理方法与措施相结合，以较少的代价获取高质量的软件。 ●The IEEE Computer Society：是(1) 将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过 程，即将工程化应用于软件中。(2) 对(1)中所述方法的研究。 2)软件过程 ●软件过程是指软件开发人员开发和维护软件及相关产品（如项目计划、设计文档、代码、测试用例、用户手 册等）的一套行为、方法、实践及变换过程 ●根据IEEE对软件过程概念的解释，软件过程涵盖了软件采购、软件开发、软件维护、软件运行、软件获取、 软件管理、软件支持等7大类的软件活动 ●ISO12207分别将这些活动归结为基本过程、支持过程和组织过程等3大类 3)软件过程工程 为建造软件过程所进行的一系列工程化活动，包含如下基本活动：过程定义、过程例化、过程模拟、过程运作。 现代软件工程=软件项目工程+软件过程工程，这标志着软件过程的时代的到来。 4)软件配置管理 SCM是标识和确定系统中配置项的过程，在系统整个生命周期内控制这些项的投放和变动，记录并报告配置的状态和变动要求，验证配置项的完整性和正确性（GB/T11457-1995软件工程术语）。 针对SCM在软件生命周期各阶段所起的作用，一个完整的SCM环境要求具有版本控制、变更管理、状态统计、和配置审计的功能。 5)CMM CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM 的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。 6)CMM中的关键过程域 每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程方面，它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域。 ●确定了实现一个成熟度级别所必须解决的问题 ●处于级别3的机构，必须解决级别2和级别3的所有关键过程域中的问题 ●每个关键过程域都确定了一套相应的活动，完成了这些活动，就达到了被认为是对改进过程非常重要的一组 目标 ●目标说明了每个关键过程域的范围、界限和意义 ●对于满足关键过程域的机构，一个关键过程域的所有目标都必须实现 ●每个关键过程域的目标总结了它的关键实践 7)CMM中的关键实践 是指关键过程域种的一些主要实践活动。每个关键过程域最终由关键实践所组成，通过实现这些关键实践达到关
第十一章项目风险管理 风险管理概述 工程项目是一种一次性、独特性和不确定性较高的工作，存在着很大的风险性，所以必须开展项目风险管理。 工程项目的实现是一个存在着很大不确定性的过程，因为这一过程是一个复杂的、一次性的、创新的，并涉及到许多关系与变数的过程。工程项目的这些特性造成了在项目的实现过程中存在着各种各样的风险，如果不能很好地管理这些风险将会造成项目的损失，甚至导致项目目标不能实现。 项目风险管理的主要任务是对工程项目实现的过程中的不确定性和风险性事件或问题的管理。 风险概念：是指由于但是者不可预见的因素，使得最终结果与但是者的期望城市较大背离，并存在使当事者蒙受损失的可能性。 项目风险的概念：是指由于项目所处的环境和条件本身的不确定性，和项目业主/顾客、项目组织或项目的某个当事者主观上不能准确预见或控制的因素影响，使项目的最终结果与当事者的期望产生背离，并存在给当事者带来损失的可能性。 项目风险管理角色描述 工程项目风险管理贯穿于工程项目实现的全过程，对于工程项目的承包方，从准备投标开始直到保修期结束。在整个过程中，因各阶段存在的风险因素不同，风险产生的原因不同，管理的主要责任者、管理方法手段也会有所区别，在项目经理承接该项目之前，风险管理的责任主要集中于企业管理层，并主要是从项目宏观上进行风险管理，而工程项目一旦交由项目经理负责后，项目风险管理的主要责任就落实到项目经理以及项目经理所组建的项目团队。 但无论谁是项目风险管理的主要责任人，对于项目整体，都要贯彻全员风险管理意识。 项目风险管理流程（见附图） 风险管理规划（从属于项目管理计划） 11.4.1项目风险管理规划的依据 事业环境因素、组织过程资产、项目范围说明书、项目管理计划书 11.4.2项目风险管理规划的方法
测试质量衡量标准 质量衡量标准(标尺) 可清晰量化的衡量产品质量 测试覆盖率-代码块覆盖,功能覆盖,用例覆盖....这么多覆盖率,每个覆盖率,合理的目标是多少?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．基于“验收测试”的原则： 很多公司都是做项目软件，如果这种要确定测试结束点，最好测试到一定阶段，达到或接近测试部门指定的标准后，就递交用户做验收测试。如果通过用户的测试验收，就可以立即终止测试部门的测试；如果客户验收测试时，发现了部分缺陷，就可以针对性的修改缺陷后，验证通过后递交客户，相应测试也可以结束。
龙源期刊网 https://www.doczj.com/doc/7e1265455.html, 建设工程项目风险管理分析 作者：戴慧颖 来源：《城市建设理论研究》2014年第06期 摘要：工程项目合同和风险管理是企业经济效益得到保证的基础，笔者结合多年的建设工程项目的管理工作经验，通过对合同风险的控制和项目风险的控制谈谈对合同管理和风险管理的认识。 关键词：工程项目；风险管理；分析 中图分类号： X820.4文献标识码： A 引言 建设工程风险管理是从工程风险相关基本概念出发，分析工程风险形成的机理，以风险分析、风险识别、风险评估、风险预警、风险应对为主线，展开风险管理基本理论与方法的论述；强调风险事前控制的重要性，即强调预警在风险管理中的重要地位，注重方法在实际工程中的运用；以最少的成本保证工程总体目标实现的管理工作。 一、项目风险管理的必要性 1、风险管理直接关系到企业的经济命脉 承包商结合具体的施工方案对各方面的资金进行合同分配。特别是建材采购这方面，建材价格容易出现波动，而承办方又需要囤积建材，这样库存的压力将会大大增加。这种情况承包商就可以利用合同约定建材价格随着市场价格的波动而调整。非常有效避免了库存需要消耗的资金。 2、项目的顺利进行更多在于项目成员多方配合 在实际过程中由于项目成员之间的权利、利益相互错杂，容易发生纠纷。项目风险管理能够协调各方的权利分配和利益均衡。明确规定各方职责，制定线性负责人，给与一定的权利和义务。这样多方在风险发生时也能根据自己的职责进行风险预防。同时，项目合同对负责人进行监督管理，避免发生权利滥用和责任推诿。 二、建设工程项目风险识别 风险识别是项目风险管理中最初始的环节，是项目风险度量、项目风险控制、制定项目风险应对措施等项目风险管理工作的基础。项目风险识别的好坏、全面、完整与否，直接决定着项目实施的成败。项目风险识别的过程是一个动态的过程，在各种项目信息和周围条件变换的
度量与分析过程 文档编号：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.过程概述 度量与分析过程的功能是从各种工程和管理过程中收集和分析度量数据并为相关的干系人报告度量结果，提供用于监控和改进项目过程和产品质量的管理信息。 度量与分析过程包括下列活动： ●定义度量与分析规格说明； ●实施项目度量与分析活动，并提供相应的结果；
- 如何进行有效的软件度量 什么是软件度量 软件度量（Software Measurement）是通过各种不同的量度(metric)对软件生命周期中的各个元素进行度量(Measure)，它能够为项目管理者提供有关项目的各种重要信息，同时也是进行大多评估活动的基础。 "软件度量"是一个包含很多完全不同的活动的术语。它主要包括：费用和工作量估计模型和度量、生产率度量模型和标准、质量控制和保证、数据收集、质量模型和度量、可靠性模型、性能评价和模型、算法/计算复杂性度量、结构和复杂性度量、GQM法(Goal/Question/Metric)、其他等。 通常度量程序是由一些软件工程组在组织中进行实施，而这种用于量化软件过程的决策手段实际上能为所有涉及软件的人或部门带来好处： 1.项目经理得益于在计划及控制软件项目时作出相关决策； 2.项目成员能聚焦于工作的改进； 3.软件配置管理组能关注于产品的完整性； 4.软件质量保证组则能专注于过程的保证； 5.当然用户则关于软件产品的最终使用； 6.除此以外，其他涉及并关心软件过程及产品的职能部门都能以此作出相关决策。为什么需要软件度量 在软件开发中，软件度量的根本目的是为了管理的需要，利用度量来改进软件过程。 在软件开发的历史中，我们可以意识到，在60年代末期的大型软件所面临的软件危机反映了软件开发中管理的重要性。而对于管理层人员来说：没有对软件过程的可见度就无法管理;而没有对见到的事物有适当的度量或适当的准则去判断、评估和决策，也无法进行优秀的管理。 我们说软件工程的方法论主要在提供可见度方面下工夫。但仅仅是方法论的提高并不能使其成为工程学科，这就需要使用度量。 度量是一种可用于决策的可比较的对象。度量已知的事物是为了进行跟踪和评估。对于未知的事物，度量则用于预测。 事实上现在在软件工程的主流里度量却被忽略了。现在的情况是： ■当我们在设计和开发软件产品的时候，我们并未能制定出度量的目标。例如：我们保证说我们将使用户界面友好、可靠、易于维护;而并未使用度量的术语来详细说明它们的具体含义。Gilb曾经说过：所谓模糊目标定理，就是没有明确目标的项目将不能明确地达到它的目标。 ■我们未能对构成软件项目实际费用的各个不同的部分进行有效的度量。譬如：通常我们并不知道，和测试阶段相比，设计阶段花费时间多大。 ■我们并未试图使我们开发的产品的各种质量合格。因此我们未能使用术语(如：在一段时间里使用故障的可能性、把产品安装到新环境中需花费的工作量等)向潜在的用户说明产品的可靠性很高。 ■我们总是试图说服自己使用另一种新的革新的开发技术和方法进行软件开发 事实上，我们在软件度量方面做的工作很少很少，而且所作的度量方面的工作也与一般科学意义上的度量相分离。我们经常会看到诸如此类的话："软件的费用有80%花费在维护上。"或"软件每一千行程序中平均有55个Bugs。"。但是这些话并没有告诉我们这样的结果是怎样产生的、试验是怎样设计、执行的、度量的是那个实体、及错误的框架是什么等等。没有这些东西，我们就不能在我们自己的环境中客观地进行反复度量，重现度量的结果
工程建设项目的风险管理 工程建设项目的风险管理提要：风险责任和权力相互平衡。风险的承担是一项责任，即承担风险控制以及风险产生的损失。但另一方面，要给承担者以控制 源自计划范文 工程建设项目的风险管理 1、项目风险的识别 工程项目的立项、各种分析、研究、设计和计划都是基于对将来情况预测基础上的，基于正常的、理想的技术、管理和组织之上的。而在实际实施以及项目的运行过程中，这些因素都有可能会产生变化。这些变化会使得原定的计划、方案受到干扰，使原定的目标不能实现。这些事先不能确定的内部和外部的干扰因素，称之为风险。风险是项目系统中的不可靠因素。风险在任何工程项目中都存在。工程项目作为集合经济、技术、管理、组织各方面的综合性社会活动，它在各个方面都存在着不确定性。这些风险造成工程项目实施的失控现象，如工期延长、成本增加、计划修改等，最终导致工程经济效益降低，甚至项目失败。 对建设工程风险识别方法有：专家调查法、财务报表法、流程图法、初始清单法、经验数据法和风险调查法。通常建设工程风险损失包括投资风险、进度风险、质量风险、安全风险等四方面内容。工程项目建设中常会遇到以下几类风
险： 合同风险。合同未履行，合同伙伴争执，责任不明，产生索赔要求； 供应风险。如供应拖延、供应商不履行合同、运输中的损坏以及在工地上的损失。 新技术新工艺风险。 由于分包层次太多，造成计划执行和调整实施控制的困难。 工程管理失误。 建设工程风险识别过程 2、项目风险的监控 风险分析 要对项目进行有效的风险监控首先应进行风险分析。风险因素分析是确定一个项目的风险范围，即有哪些风险存在，将这些风险因素逐一列出，以作为全面风险管理的对象。在不同的阶段，由于目标设计、项目的技术设计和计划，环境调查的深度不同，对风险的认识程度也不相同，经历一个由浅入深逐步细化的过程。但不管哪个阶段首先都要将对项目的目标系统有影响的各种风险因素罗列出来，作项目风险目录表，再采用系统方法进行分析。
摘要：CMMI为软件产品及软件过程提供了一套定量的表示和分析，即软件度量的模型。有效的软件度量过程能促进组织的软件过程能力的改进。文章结合国内应用特点，介绍了基于CMMI的多层架构软件产品的度量模型，并着重讨论了基于CMMI的软件过程度量，总结了软件过程度量的工作方法和思路，提出了解决国内软件度量的一般性方法，为软件过程改进提供了可行的方法和实践。 关键词：CMMI；软件度量；软件过程能力；度量项；门限值 0引言 软件度量的目的是为项目管理提供项目的执行情况的充分可见性，并使项目管理者了解项目实际进展与项目计划之间的偏差，以便采取纠正行动，保证项目的顺利进行。有效的软件度量过程促进组织的软件过程能力的改进。软件度量是软件特性的定量表示和分析方法；软件度量可分为软件产品度量和软件过程度量两类。软件产品度量(定量表示和分析软件产品特性)是独立于产品生产过程的度量；软件过程度量(定量表示和分析软件过程特性)是为管理者提供产品生产过程的状态信息和指导依据。 软件产品度量的要素为质量要素、评价准则、度量元。这里软件过程度量主要通过需求度量、规模度量、进度度量、工作量度量、风险管理度量、质量保证度量来分析。 1三层架构软件产品度量 1．1质量要素 软件质量可分解成六个要素，这六个要素是软件的基本特征。功能性：软件所实现的功能满足用户需求的程度；可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度；易用性：对于一个软件，用户学习、操作、准备输入和理解输出时所做努力的程度；效率：在指定的条件下，软件实现某种功能使用计算机资源(包括时间)的有效程度；可维修性：为了满足用户需求、环境改变或发生软件错误时，对软件进行相应修改所需的努力程度；可移植性：软件从一个计算机系统或环境转移到另一个计算机系统或环境的难易程度。 1．2评价准则 评价准则包括：精确性、健壮性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、产品文件完备性。 1．3度量元 根据软件的需求分析、概要设计、详细设计、实现、组装测试、确认测试和维护与使用七个阶段，制定针对每一个阶段的度量元。 2基于CMMI软件过程度量 从软件企业的观点出发，软件度量(software Measurement)是通过各种不同的量度对软件生命周期中的各个元素进行度量(Measure)，为项目管理者提供有关项目的各种重要信息，也是进行软件评估活动的基础。 Carnegie Mellon大学的SEI提出了以下的一个软件度量过程体系结构图：
工程成本规划与控制课程教案 教案编号：CM10-001
第十章工程项目成本风险分析与管理（2学时） 一、本章教学目的 通过本章的学习，让学生了解工程项目成本构成要素的不确定性与风险管理的基本理论，学会工程项目成本风险分析的工具和技术与风险管理的手段和方法，提高风险识别、估计和评价的工程项目风险分析和管理的能力。 二、本章教学重点和难点 本章教学重点和难点是工程项目成本风险分析与管理中的风险识别、估计和评价的技术、手段和方法。 三、本章教学内容 （一）工程成本构成要素不确定性与风险管理 1.工程成本构成要素不确定性分析 （1）工程成本构成要素是随机变量 工程成本构成要素是随机变量，在于工程成本无论采用何种分类标准，其构成要素都要受自然、社会、技术、经济、法律等影响。工程成本是决定建设工程价值的重要因素，最终归为工程量和相关取费标准上，而这两个确定建设工程成本的重要方面受可控和不可控的影响因素非常多，都是随机变量。 工程成本构成要素之所以具有不确定性和随机性特征，在于以下三个原因（图10.1）：
图10.1 工程成本构成要素不确定性的原因 ① 项目环境的不确定性 工程项目的立项、分析、研究、设计和策划都是基于对未来环境（市场、经济、社会、自然等）的预测，是基于正常的或理想的技术、管理和组织。而在具体实施过程中，工程项目所处的环境因素均可能会产生变化，各方面均存在着不确定变动。 ② 工程行为主体的不确定性 工程行为主体（图10.2）包括政府部门、业主、投资者、项目管理者、承包商、咨询中介等。这些行为主体的资信、技术能力、资金实力、企业经营状况、合同执行、业务流程等差别甚大，彼此间相互作用，因此他们的行为和决策都会影响到工程成本管理
软件质量指标度量 1综述 (2) 1.1编写目的 (2) 1.2阅读指南 (2) 2软件质量指标 (3) 2.1需求功能点覆盖率 (3) 2.2用例执行覆盖率 (3) 2.3缺陷修复率（截至于**年*月*日） (4) 2.4缺陷遗留个数（截至于**年*月*日） (4) 2.5缺陷分布统计（模块缺陷率） (4) 2.6缺陷分布统计（严重缺陷率） (5) 2.7缺陷密度及收敛 (5) 3测试过程质量指标 (8) 3.1缺陷探测率 (8) 3.2有效缺陷率 (8) 3.1用例执行效率 (9) 3.2缺陷发现率 (9) 4交付质量指标 (11) 4.1加载回退率 (11) 4.2故障回退率 (11) 5版本说明 (12)
1综述 1.1编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。 1.2阅读指南 ●软件测试质量指标主要针对研发项目、商务项目被测产品出具数据 度量。 ●测试过程质量指标主要为测试经理、测试组长对测试人员的测试执 行质量出具数据度量。 ●交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用，也可结合使用。
2软件质量指标 2.1需求功能点覆盖率 【需求覆盖率】：计算测试用例总数之和除以与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。 【公式】：∑测试用例数（个） / ∑功能点（个） 说明：用例覆盖需求矩阵，一个需求对应多个功能点。 【数据来源】：《联通集中集团客户业务支撑系统销售管理用户需求说明书》《联通集中集团客户业务支撑系统销售管理需求跟踪矩阵》 【计算结果】需求覆盖率=113/8=14.13 2.2用例执行覆盖率 【用例执行覆盖率】：计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。 【公式】：∑执行的测试用例个数（个） / ∑测试用例个数（个）*100% 【数据来源】：《iSMS测试进度跟踪表》 【计算结果】：用例执行覆盖率=100%
软件测试过程的度量 1）测试度量的作用 A:为制定测试计划时提供依据 需要多长时间?需要什么物质条件？需要多少人，什么素质的人？在规定的时间内能完成到什么程度？ 哪些模块及功能需要重点关注？测试工作量占整个项目的比例？测试结束后我们能达到什么样的目标？等等 ( 这些数据是我们在项目启动过程中，制定测试计划，尤其在规划资源的过程中，一些必要的参考值。不同项目可能会有其特殊性，但从总体上看，他们还是有一些规律可寻的，过去的经验数据可以作为一个大概估算，如果项目经验丰富，那么可以从历史数据中找出和新项目类似的情况，以能更为准确的完成计划。) B：提高测试流程可控性 提高测试效率和质量 提高测试人员的成就感 2)在测试哪个过程做度量 （产品早期的市场评估、测试策略分析、可测试性需求分析、测试工具分析、用例设计阶段、执行阶段和FOA 阶段） 我们需要在测试的几个关键阶段做度量，它们分别是：用例设计阶段、执行阶段和FOA 阶段。测试用例设计阶段包括测试方案的最终确定、测试工具的设计、测试用例编写等，测试执行阶段很明显，即我们测试的各个过程，如集成测试、系统测试、性能测试、回归测试等，也包括开发人员完成的单元测试的度量工作。FOA 阶段是检验测试质量的第一步，通过FOA 我们可以获得很多为产品质量做贡献的度量，这也是体现测试价值的度量。看起来几乎包括了测试过程的全部。其实这里包括的只是测试的具体工作阶段。 3）测试度量的内容 两种度量类型： A：项目度量：规模、测试工作量、测试进度、测试生产率 B：质量度量：缺陷率（阶段）、缺陷排除率、可靠性等 四个基本度量项：规模、工作量、进度、缺陷 4) 测试用例设计阶段的度量 A：规模：测试方案数量、测试用例数量、测试工具设计数量、测试用例/人月 B：工作量：文档的草稿编写工作量、评审前阅读工作量、评审工作量、修改工作量 C：进度：每件具体工作的计划开始结束时间、实际开始结束时间、计划工时数、实际工时数、计划完成率 D：缺陷：评审过程中出现的错误数量、缺陷数量，级别 5）测试执行阶段的度量： ? 测试用例执行率? 测试用例通过率 ? 测试用例问题发现率? BUG数量 ? BUG级别统计? BUG分布统计（模块） ? BUG分布统计（阶段）? BUG密度 ? BUG关闭率? 人均BUG发现效率 ? 测试用例执行工作量项目? 回归测试执行工作量
软件项目管理 第一章 思考题： 1、当我们选择软件项目的负责人时，我们在寻找什么？ 成功的项目负责人应采用一种解决问题的管理风格。也就是说，软件项目经理应该注重理解要解决的问题、把握住涌现的各种意见、同时让项目团队的每一个人知道质量很重要，不能妥协。 2、选择软件团队的结构时，应该考虑哪些因素？ （1）待解决问题的难度；（2）开发程序的规模，以代码行或功能点来度量；（3）团队成员需要共同工作的时间（团队生存期）；（4）能够对问题做模块化划分的程度；（5）待开发系统的质量要求和可靠性要求；（6）交付日期的严格程度；（7）项目所需要的友好交流的程度。 3、定义软件的结构时，我们有哪些选择？ 封闭式范型。按照传统的权利层次来组织团队。当开发与过去已经做过的产品相似的软件时，这种团队十分有效。但在这种封闭式范型下难以进行创新性的工作。 随机式范型。松散地组织团队，团队工作依赖于团队成员个人的主动性。当需要创新或技术上的突破时，按照这种随机式范型的团队很有优势。但当需要“有次序地执行”才能完成工作时，这种团队就会陷入困境。 开放式范型：试图以一种具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团队。工作是大家相互协作完成的。良好的沟通和根据团队整体的意见做出决策是开放式范型的特征。开放式范型的团队结构特别适合于解决复杂的问题，但可能不像其他类型的团队那么有效。 同步式范型。依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没有什么交流。 4、何谓有凝聚力的团队？ 一个有凝聚力的团队是一组团结紧密的人，他们的整体力量大于个体力量的总和。与一般团队相比，有凝聚力的团队成员有更高的生产率和更大的动力。他们拥有共同的目标和共同
软件开发度量及考核方法 一、引言 如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。虽然目前很多公司有这方面的绩效考核，但是由于软件开发行业的特殊性，大多数公司没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。所以根据以前经验和相关的资料编写了适用于本部门的度量和考核方法。该考核方法是技术支持部软件开发人员和测试人员的试行版本。 二、目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 三、考核实施办法 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在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。