1、软件项目度量3、项目过程的度量项目过程的度量主要包括进度度量和工作量度量。（1 ）进度度量进度度量主要关注项目执行过程中，项目的实际进度与项目计划的偏差情况，进度度量的主要目的是客户反映项目的真实进展情况，并不剖析进展偏差的原因，对于负责多个项目管理的公司高级主管来说，及时客观掌握项目的真实进度是至关重要的。进度度量需要项目经理在制定计划的过程中对 WBS 做认真分析，不仅仅要清晰定义每项任务的工期、投入的资源以及预计的起止时间。然而目前许多项目计划还远没有达到对每项任务做认真分析的程度，例如，滚动任务计划需要及时计算关键路径，对于非关键路径上的任务实际上起止时间包括两组，分别是最早开始时间和
2、最早结束时间、最晚开始时间和最晚结束时间。在最早开始时间和最晚开始时间之间的这一段称为“浮动时间“，浮动时间对于资源平衡非常重要。假定上图中每个方框表示一项任务，红色框表示关键路径上的任务，黄色框表示非关键路径上的任务。那么对于任务 F、G、H 来说，应该有浮动时间，在浮动时间内完成的任务属于计划内完成的任务。目前许多项目计划中仅列出“开始时间“ 、“结束时间“，但并没有清晰说明这两个时间的约束性条件，对于进度跟踪和资源平衡非常不利。对每一项任务的预计开始时间、预计结束时间，以及对实际开始时间、实际结束时间的记录就如同需求度量中的需求变更记录表一样，属于原始细节级的数据，其本身虽然产生度量指标
3、（单项任务的进度偏差），但这些指标只有按照某种规则进行统计汇总之后才具备反映项目总体紧张的能力。例如很多项目采用里程碑分析方法，对进度偏差进行分析，如下表对某个项目的各个主要阶段的进度偏差进行了统计：开始日期（YYYY-MM-DD）完成日期（YYYY-MM-DD）工期 (天 )阶段计划 实际 计划 实际 计划 实际工期偏离率 %时间平滑率项目计划 2002-1-2 2002-1-202002-3-4 2002-3-24 62 64 3.23 32.26需求分析 2002-4-5 2002-4-5 2002-5-7 2002-5-11 32 36 12.50 12.50概要设计 2002-5-6
4、 2002-5-9 2002-6-8 2002-6-20 32 41 28.13 37.50详细设计 2002-6-7 2002-7-7 2002-8-9 2002-8-24 62 47 -24.19 24.19编码 2002-6-8 2002-6-9 2002-8-10 2002-8-12 62 63 1.61 3.23单元测试 2002-7-7 2002-7-9 2002-8-19 2002-8-20 42 41 -2.38 2.38集成测试 2002-9-102002-9-102002-9-22 2002-9-22 12 12 0.00 0.00系统测试 2002-9-232002-9-
5、242002-10-102002-10-1117 17 0.00 5.88根据这个表格可以输出用于项目分析的进度图表，基于这样的图表，可以对整个项目执行过程中的进度偏差一目了然，对于具有多个项目的组织来说，将多个项目的进度偏差曲线放在一起进行对比分析，可以得出项目的一般性规律，在项目计划改进时这些知识将具有非常高的实用价值。 （2 ）工作量度量工作量度量的主要指标是在项目执行过程中各任务或各类任务，或者各个阶段投入的工作量的跟踪指标，以及与计划相比的偏差指标。工作量度量同样依赖于项目计划中任务分解结构的详细分析，确定的资源投入和成本预算都是经过认真评估，否则会引起计划的可执行性降低，工作量统计
6、也就失去了科学的依据和基准。工作量度量还需要项目管理制度中明确项目经理或者其他角色对项目计划的全局执行情况保持高度的关注，以保证每项任务的开始时间和结束时间以及投入的资源、产生的成果都能够被记录在案，只有这样，才可能获得真实、全面的工作量度量数据。工作量度量的数据统计实际上包括了数据收集过程和数据的统计分析过程。工作量度量指标按照项目中任务的分类包括以下几类：项目任务活动分类 项目任务细分项目管理活动工作量 项目估计项目计划准备评审项目计划更新 WBS 计划项目启动项目周例会项目里程碑会议项目度量活动项目月度会议项目跟踪项目总结配置管理活动工作量 配置管理计划准备评审配置管理计划修改配置管理计
7、划配置库维护发布配置状态报告配置审计质量管理活动工作量 质量保证计划准备评审质量保证计划修改质保计划SQA 审计SQA 验证活动为项目组提供培训项目组公共活动工作量 培训学习项目组外活动 请假（休假）会议出差需求分析活动 需求规格说明书准备需求规格说明书评审需求规格说明书修改概要设计活动 概要设计说明书准备概要设计说明书评审概要设计说明书修改详细设计活动 详细设计说明书准备详细设计说明书评审详细设计说明书修改编码活动 编码代码走查代码修改单元测试活动 单元测试计划与用例准备单元测试计划与用例评审单元测试计划与用例修改单元测试执行集成测试活动 集成测试计划与用例准备集成测试计划与用例评审集成测试
8、计划与用例修改集成测试执行系统测试活动 系统测试计划与用例准备系统测试计划与用例评审系统测试计划与用例修改系统测试执行项目结束活动 产品发布项目验收项目结项需要度量的指标并不多，主要包括以下三个：A计划工作量（人时数或人日数）：项目计划中某项活动或某类活动预计发生的工作量B实际工作量（人时数或人日数，与计划工作量采用同一单位）：截至某点或项目结束后统计得到的某项活动或某类活动实际发生的工作量C工作量偏差：（实际工作量计划工作量）/计划工作量 100工作量度量的数据可以用作比例分析，获得项目执行过程中各种活动的工作的分配情况，例如某个项目各类活动的工作量统计表如下表所示： 俗话说“没有比较就没有
9、鉴别“，利用单个项目中各种活动消耗的工作量比例图可以对项目的工作量分配有个清晰的认识，如果将多个项目进行对比，则可以发现各个项目的差异所在。同时在同一项目的实施过程中，对关键活动的工作量消耗做横向对比，可以发现“学习曲线“的情况，越晚启动的项目执行的效率应该越高，如果违背了这个规律，则需要对项目进行专门分析，剖析原因所在。（3 ）项目进度、工作量和成本综合度量（挣值分析法）挣值分析是在对范围、进度和成本进行综合测量的基础上评价项目绩效的一种方法。它涉及每项工作的 3 个关键值：计划值（PV）在规定的时间内在工作上将要花费的获得批准的成本估算部分实际成本（AC）在规定时间内完成工作所花费的实际成
10、本（直接和间接成本的总额）挣值（EV ）实际完成工作的价值这 3 个值的综合使用可以提供评价工作绩效好坏的尺度。最常用的尺度是：成本偏差（CV）=EV-AC进度偏差（SV）=EV-PVCV 和 SV 这两个值，可以转化为效率指示器，反映任何工作项的成本与进度计划绩效。成本绩效指数（CPI）=EV/AC进度绩效指数（SPI）=EV/PVCPI 被广泛用于预测完工时的项目成本。SPI 有时与 CPI 一起被用于预测项目完工估算。完工估算（完成全部工作所需的成本）的计算公式如下：EAC=总预算/CPI or EAC=AC-（总预算-EV ）/CPI挣值分析具有将进度、工作量和成本综合起来的特点，并且
11、具有可视化的优点，已经在各行业的项目管理中广泛采用，同样，在软件开发项目中，挣值分析也具有非常高的实用价值。挣值分析的原理和方法本身并不复杂，本文也不会过多讨论如何实现挣值分析，解释挣值分析几个指标的含义，但需要特殊说明的是使用挣值分析的一些必备条件：A在挣值分析中，一项任务的状态只有两种，即“完成“、“未完成“ ，这一假设是挣值管理的重要理论基础，但在实际的软件开发项目中，许多任务分解的情况粒度仍然比较粗，在任务执行过程中需要加入一些检查点，但检查点并不输出最终的成果。 在这种情况下，需要计划制定者以及任务分配者将任务分解到“原子“ 级别，能够比较方便地判断完成与否的状态，否则使用挣值分析法
12、的数据统计结果会有比较大的延迟，反映的项目实际运行状态至少是不及时的。B在挣值分析中，要求每项任务状态标准是客户现实的，标志为完成状态的任务如果在后续发现了错误需要重新返工，则挣值分析曲线上会反映出异常的情况，如果这种返工比较频繁的变化，挣值分析曲线则几乎完全反映不了项目的进度情况，当然，在这种情况下，项目的实际进度确实是难以表述，无法说清的。因此挣值管理得以运用的另外一个重要前提是项目管理得当，项目在进度控制之下进行，也就是说项目管理手段保证了项目任务在沿着计划的大方向在前进。C在高度不确定的项目中，例如预研性质的项目，因面临大量的技术难题，或者创新性的任务，这些任务的特点是无法预先估计解决
13、问题的时间，并且一个新的课题中，面临的各种困难很可能互相影响，有可能从进度上看，很长时间处于停滞状态，但突然全部完成。对于这种项目来说，无论是项目管理制度、方法，还是项目度量方法都应该符合项目的实际特点而作，而一般开发、工程类的项目的项目管理方法和挣值分析法在这类项目中都不适用。因此，挣值分析法并不是包治百病的灵丹妙药，在实际应用时需要根据项目特点进行选择。4、项目成本的度量项目成本包含的因素众多，并不是仅计算项目自身的财务消耗情况就能够全面概括出来的，但财务消耗（预算使用情况）无疑是成本度量的重要指标。对于不同的项目来说，项目成本的构成要素也有所不同，下面列举两种典型的情况：（1 ）产品化开
14、发的软件项目产品开发项目的特点是开发团队集中，大多采用项目型的组织结构进行管理，项目组成员职责清晰，项目经理对项目组成员的工作有统一的监管，在这种情况下，项目成本比较适合以项目为单位进行成本度量。产品化开发（项目型组织结构）的项目成本度量主要指标包括：A项目成员工资：在软件开发企业中，项目成本主要体现在人员工资上，在项目型的结构中，项目组成员的工资成本应作为项目成本进行统计；B开发环境建设成本：进行产品开发需要为开发人员配置开发用的设备，根据项目的不同，这项成本可能有很大的差异，但一般情况下开发环境建设成本应该包括开发人员使用的电脑硬件和基本软件费用、开发用服务器的硬件和软件费用、网络设备费用
15、、项目管理软件工具费用等；C培训费用：为提高开发人员的技能，不论大型项目还是小型项目，均有可能需要对开发人员进行相应的技能培训，这种培训不仅包括对开发工具本身的培训，还可能包括对业务领域知识的培训、对项目管理规范的培训等。这些费用中除包括培训消耗的开发成员的工作量产生的成本之外，还包括聘请培训教师费用、购置培训教材的费用，以及培训场地等培训组织费用。D公用费用：公用费用并没有明确的界限确定要包含哪些科目，但在一个中型或大型项目中，公用费用一般会包括项目团队在项目执行之外的活动组织费用，以及用于与最终用户沟通的费用，以及因调研或其他活动产生的差旅费用等。需要说明的是，如果大多数项目度量指标一样，
16、成本度量的指标粒度越细越好，对指标的分类越细致，成本分析和成本控制越具有针对性。在项目型组织结构管理之下的产品化开发项目的成本度量指标表举例如下：编号 成本类别 成本科目 备注1 人员工资1 1 开发人员工资 隶属项目组织的项目成员工资1 2 项目管理者工资 隶属项目组织的项目管理者工资1 3 外聘专家&其他人员报酬 与项目开发相关，但不属于项目组织成员的其他人员的报酬2 开发环境建设成本2 1 开发人员用硬件设备成本2 2 开发人员用系统软件 包括 Windows 等与硬件配套的操作系统软件2 3 开发人员用的办公软件 包括 Office 等需要付费购买的软件2 4 开发人员用开发工具软件
17、不同的项目会有不同的工具软件，类似 Visual Studio、Borland CBuilder 等，以及 Case 工具2 5 开发环境公用的服务器硬件 包括服务器主机和存储设备等2 6 开发环境服务器系统软件 类似 Windows 2000 Server类的服务器操作系统软件2 7 开发环境服务器应用软件 类似数据库服务器软件、J2EE Application Server 等3 培训成本3 1 培训资料费用 包括为学员购买的培训资料、参考书籍和软硬件等3 2 培训教师报酬 如果外聘培训教师，则需要列入培训成本中3 3 培训组织费用 包括培训场地租金，向培训组织者支付的服务性费用等4 公用
18、成本4 1 项目活动组织费用 为增强项目团队成员间的非正式沟通和交流而组织的开发外活动发生的费用4 2 与客户沟通费用 包括通信费用、产生的差旅费用以及商务招待费用、礼品等4 3 加班费用 加班支付的报酬、额外的交通通信补贴等费用均属此列（2 ）工程类项目（采用矩阵结构进行项目管理）目前有非常多的项目是依照客户的要求进行定制，例如在中国移动通信公司建设的综合经营分析系统是一个数据仓库项目，中国移动总部制定基本框架性的业务规范，但各省分公司按照各自的个性化需求独立进行招标，在这种情况下，承担中国移动多个省分经营分析系统建设的软件开发商面对的多个项目具有相当的共性，同时又有所不同。在这个例子中，软
19、件开发商承担的多个项目中因具有较强的共性，开发过程中为了复用开发成果和开发人员，采用矩阵式的项目管理看来是顺理成章；同时因各个项目的需求又有所差异，因此软件开发商开发出来的系统产品化程度还不是非常高，因此还需要进行本地化开发，本地化开发一般需要在客户现场进行。这种开发模式显然比集中式的产品开发复杂程度要高，不但项目管理的复杂性提高，项目成本的度量体系也较产品开发更加复杂，这时项目成员不再专属某个项目，成员工资也不单独由项目组控制，如果仍要以项目为成本核算单位，同时由不与职能部门自身的成本核算体系发生冲突，则需要对成本度量体系进行专门的设计。在矩阵型管理结构中，如果要对项目成本进行度量，一个重要
20、的前提条件是在任务分派的时候能够清楚明确地说明该项任务属于哪个项目，这样才能将职能部门成员产生的工作量计入项目成本，按照固定的时间周期（例如每月）对每个职能部门成员在各个项目中的工作量进行统计，并对工资成本进行折算，从而得到项目的人力工资成本数据。矩阵结构中项目成本度量的另外一个前提条件是建立了工作量统计制度，以及项目成本核算体系，这些制度和体系需要有明确职责的人执行，否则项目经理无法获知职能部门中的项目成员发生的成本情况，职能部门经理不能获知项目其他类型的成本，公司的高层管理者也因不同部门报告的成本体系之间的交叉和疏漏而无法得到项目成本的真实数据。很多公司都会做工作量在各项目中的分配情况的统
21、计，比较常用的一种统计表格如下：人员 1 2 3 4 5 6 7 上海北京辽宁安徽江苏陕西山东四川核定总计 实际总计A 5 17 22B 10 12 22C 22 22D 9 6 15E 22 22F 2 16 18G 8 10 18H 8 1 11 20I 辽宁 5 7 1 9 22在这个工作量统计表中，可以看到组织内每个成员在不同项目中投入的工作量，借此可以计算项目的人工成本；如果按月进行累计，则可以看到每个月各个项目投入的总工作量。在本节示例中的项目情况在很多公司存在，因此也非常具有代表性，在这种项目中，项目度量指标体系也与产品开发型的项目有所不同，说明如下：A人工工资成本前面已经论述过
22、有关矩阵结构中项目人工成本的统计计算方法，核心思想是要对矩阵中每个成员的工作量统计到各个项目中去，用于成本核算。B项目差旅费在现场开发的项目成员产生的差旅费用包括交通费用、差旅补贴费用、住宿费用、以及在现场发生的其他费用。C项目公用费用矩阵结构中的项目公用费用与集中式的产品开发中的项目公用费用有所不同，矩阵结构开发模式中的项目公用费用除项目活动经费、加班费用（现场开发还可能不列支加班费用），在现场还包括公司为出差的项目成员日常生活、办公支出的费用项。D有关培训成本和开发环境建设成本，在矩阵结构中一般不列为项目成本，因对员工的技能培训不仅仅单独为某个项目服务；同时开发环境建设也属于多个项目公共使
23、用，这些相关费用可以作为组织整体成本进行计算。矩阵型项目结构中项目成本的度量体系分解可参考以下表格：序号 费用分类 费用项 说明1 人员工资2 项目差旅费2 1 差旅交通费2 2 差旅补贴费用2 3 住宿费用2 4 其他费用3 项目公用费用3 1 项目活动经费3 2 加班费用3 3 现场办公场地或宿舍的公共费用从上面的表格看上去，虽然矩阵型结构的项目管理和成本度量都更加复杂，但成本度量表却比价简单，但这决不意味着矩阵型结构的成本度量很容易，事实上，由于很多成本跨越了多个项目无法摊分，而将成本项目列入了整个组织的成本。一般情况下，按照这种度量体系进行的成本核算，职能部门经理可以了解各个项目中的人
24、员工资成本；项目经理可以对项目公用费用和差旅费进行核算；而高层经理则可以通过项目经理和职能经理了解各个项目的综合成本以及整个组织内的公共成本。（3 ）企业成本的项目摊分以上虽然已经细致讨论了项目成本的度量体系，但由于项目自身的复杂性和项目与企业整体组织运营的关系，这些指标还不能完全客观真实地反映项目的全部成本，重要的遗漏就是企业成本的摊分。以项目为业务主体的公司，几乎所有的利润都由项目产生，但并不是所有的支出都用于项目的开发过程，在公司内还有行政部门、财务部门、人力部门、质量部门、市场销售部门的相关的各种配套部门为项目提供支持，这些部门的运营成本，以及企业运营产生的场地租金、水电、办公、营销等
25、费用如果都摊分到项目中去，才算彻底的以项目为企业成本度量体系，在项目预算中才能更加客观地衡量项目支出与预期收入的比例关系，项目预算也才能与企业盈利目标结合起来。但现实的情况这些摊分的成本指标很少能够进入项目的度量体系中，一方面是因为这些摊分的计算方法本身比较复杂，按照怎样的标准在项目中摊分缺乏科学统一的方法；另一方面这些数据并不在项目经理或职能经理甚至高层主管的控制之下，这些数据可以统一从财务部门进行统计，但鉴于企业的实际运作情况，并不一定将具体的科目和成本数据向其他部门公开。尽管成本摊分有一定的困难，但还是有一些简单的方法可以纠正项目成本度量体系中存在的这种不足，常用的方法是根据企业总成本（
26、扣除上述方法得到的项目成本之外）按照企业员工数量进行均分，再折算到项目消耗的工时上，即可以对项目成本数据进行初步纠正，使之更加符合实际情况。计算公式如下：摊分成本（单位时间内企业总成本（扣除已计算的项目成本）/企业员工总数）项目人数项目历时 5、项目质量的度量项目质量度量是项目中最常用的度量，这一方面是因为软件质量更加容易被人们所重视；另一方面是因为软件质量度量有很多成熟的方法和工具，在很多公司被普遍使用。就软件质量度量的重要性来说，虽然质量很重要，但对于项目来说，质量只不过是项目三角形的一个边，因此本文中讨论的项目度量体系中同时讨论进度度量、成本度量和质量度量。 对软件质量的度量标准采用 B
27、ug 数量作为度量指标的比较多，甚至有很多组织用 Bug 数量作为质量度量的唯一指标，但这显然是有失科学性的，在现代软件开发项目管理中对质量的定义更加宽泛，已经不再是“bug 数“ 这么简单了。在国家标准信息技术软件产品评价 质量特性及其使用指南中对质量的定义如下：软件质量 software quality与软件产品满足明确或隐含需求的能力有关的特征和特性的总和。这个标准符合业界对软件质量的普遍理解，符合用户需求的软件才能被视为高质量的软件。从侧面讲，用户满意度高的软件才是高质量的软件，因此客户满意度指标也可以作为软件质量度量体系中的一个参考指标。对于软件质量的理解目前主要有三种观点，也可以看
28、作对同一问题的三个角度的说法：1)用户观点GBT 658392 中的质量定义反映了用户观点，本标准的特性定义也反映了此观点。用户主要感兴趣的是使用软件、软件的性能和使用软件的效果。用户评价软件，对软件内部的各方面或软件是如何开发的情况一无所知。用户的问题会包括：-软件是否具有所需求的功能？-软件的可靠程度如何？-软件的效率如何？-软件使用是否方便？-该软件转移到另一环境是否容易？2)开发者观点由于软件质量特性对需求和验收均适用，故开发过程要求用户和开发者使用同样的软件质量特性。在开发现行软件时，隐含的需求必须反映在质量需求中。由于开发者负责生产满足质量需求的软件，放他们对中间产品质量以及最终产
29、品质量都感兴趣。为了在各个开发阶段评价中间产品质量，开发者不得不对同样的特性使用不同的度量。因同一度量不适用于生存周期的所有阶段。例如考虑效率时，用户用响应时间，而开发者在设计规格说明中则必须用路径长度、存取时间和等待时间。一般而言，适用于产品外部接口的度量被那些适用于它的结为的度量达所取代。开发者的观点还必须体现维护软件者需要的质量特性观点。3)管理者观点管理者也许更注重总的质量而不是某一特性，为此须根据商务需求对各个特性赋于权值。管理者还需要从管理的准则.诸如进度拖延或成本超支。与质量的提高之间进行权衡。因为他希望以有限的成本、人力和时间使质量达到优化。鉴于软件质量度量标准的复杂性，本文讨
30、论的软件质量度量并不重点关注如何发现 Bug，并统计 Bug，以及跟踪 Bug 数量的变化等内容，这些内容虽然属于质量范畴，但更多地属于软件测试（Test）的范畴，与质量度量这个主题从内容含义上还是有所区别的。下面列举某软件公司 ISO 体系文件中对开发部门提出的质量目标：1. 软件产品发布合格率达到 100%2. 系统测试中每个模块功能 bug 少于 4 个，总体性能 bug 少于 2 个3. 每一个版本的功能和性能性 bug 处理比率大于 90%4. 工程实施中每项故障解决后，再重复出现的比率应小于 10%5. 产品维护过程中每时期存在的 bug 总数呈递减趋势6. 顾客满意度在 95%以
31、上，每年递增 1%一般来说，质量体系的分解层次是部门质量目标要符合公司质量目标，项目质量目标则要符合部门质量目标，这样才能保证整个公司作为一个组织整体的质量得以保证。同时需要关注的一个重要问题是，在这个组织中确实将客户满意度的度量指标作为质量指标，这表明客户满意度在软件质量度量中的重要参照作用。同时质量度量指标中对“Bug 数“这样一个看似简单的度量指标做了更加全面的规定，例如在系统测试过程中每个软件模块中的数量，Bug 的处理比率以及 Bug 的重现趋势等。Bug 统计的观点实际上是将软件需求中不符合项都作为 Bug 来看待，因此也符合“质量是符合需求的特性集合“这样的观点，之所以绝大多数公
32、司并不将软件需求中的“功能性需求“ 、“性能需求“、“灵活性需求“、“安全性需求“、“ 易用性需求“等作为独立的质量度量指标，也是因为在软件开发过程中，这些软件质量特性的最终符合程度均采用测试手段进行验证，而测试结果输出的数据结果对于不符合需求的点来说，就是所谓的 Bug。对软件质量度量指标的收集并不是质量度量的目的，度量的价值就在于在基于数据分析的基础上进行过程改进。以下是一个软件项目缺陷统计的实例：缺陷缺陷引入阶段 缺陷影响度阶段/活动缺陷合计 需求 设计 编码测试计划与用例 文档 其他 严重 一般 建议客户标识缺陷 合计System Requirement System Req 0 SF
33、T Plan 0 AT Plan 0 System Design System Design 0 SIT Plan 0 需求分析 32SRS 10 10 9 15 9 系统测试计划 22 1 21 3 12 16 概要设计 20概要设计说明书 20 6 14 1 18 7 详细设计 40详细设计说明书 23 2 21 2 23 3 集成测试计划 17 0 1 16 0 7 13 编码 89代码 68 0 14 54 3 49 33 单元测试计划 21 0 0 12 21 2 18 6 测试 126单元测试 59 1 2 45 11 10 55 7 集成测试 42 0 14 23 5 4 34
34、11 系统测试 25 4 6 4 11 1 1 6 发布 46其它 46 2 10 34 合计 353 26 82 172 85 0 0 35 232 111 353以上表中的数据为例，可以对缺陷在各个阶段的分布情况作构成分析，如下图： 构成分析可以在各个质量维度上使用，包括缺陷引入的阶段、缺陷发现的阶段、不同性质的缺陷数量等，构成分析的妙处在于很容易发现“8020 规则“，即 80的缺陷都是由 20的原因造成的，这对质量改进具有非常高的价值。对与同一软件的不同版本之间或项目开发过程中不同时期的 Bug 数量的统计，还可以发现Bug 数量的总体趋势，并发现组织内软件开发过程中质量问题的一般性规
35、律，对于从组织层面进行质量管理也非常具有实际意义。6、风险度量有人说风险管理是项目管理中的最高境界，这话有一定道理，如果一个项目能够预见到所有风险并且能够事先规避的话，项目进度就会非常顺畅了，但这只是一种理想情况，实际上很多项目在开发过程中还是会遇到各种各样的未曾预知的问题。这个问题应该说与风险量化技术在项目管理中采用的程度有很大关系。风险管理的一般过程如下： 一般风险识别过程和风险分析过程采用头脑风暴法进行讨论，并根据讨论的结果形成风险管理计划，在项目执行的过程中，同时执行并跟踪风险管理计划，并定期对风险进行评估和分析。风险度量技术主要在风险分析过程中采用，风险管理文档的主要内容以及需要度量
36、的几个主要指标说明如下：内容 目标风险说明 捉住风险的本质风险发生可能 描述风险发生的可能性，需要量化风险的严重性 风险发生造成的影响，需要量化风险披露 说明风险发生时造成的总体影响风险缓解计划 描述防止或降低风险的措施应急计划 描述风险发生后要做什么，以及何时去做风险负责人实际上风险分析过程中最为主要的度量指标只有两个：风险发生的概率和风险发生之后后果的严重程度。对风险的综合评估可以对每个风险项根据这两个度量指标进行计算：风险分值发生概率风险后果严重性。 而跟踪分值最高的风险，采取措施进行规避或提前准备应急方案会对项目整体的进展产生非常积极的作用。 而跟踪分值最高的风险，采取措施进行规避或提前准备应急方案会对项目整体的进展产生非常积极的作用。
