2018-06-17 11:41:14 seagal890 阅读数 1291
  • 大规模敏捷需求管理

    课程介绍一个具有操作性的大规模敏捷需求管理方案。这个方案平衡需求运作的灵活性和规律。方案包涵大型需求管理各环节,从需求价值分析需求,决策、可视化、度量、验证、等。如果你团队或组织面临需求管理的挑战,不妨听听这个课程,让我们协助你团队建立良好的需求管理习惯持续改进。

    5854 人正在学习 去看看 CSDN讲师

测试度量是非常重要的。它可以帮助测试团队追踪测试活动的有效性,也可以为测试过程的改善、测试活动的改善、各类报告提供有力的支持。它可以帮助测试组织从更高层次上实施一些评估活动和改善活动。

测试度量的分类

  • 项目度量
  • 产品度量
  • 过程度量
  • 人员度量

监督测试进展主要就以下五个方面:

  • 产品(质量)风险
  • 缺陷
  • 测试
  • 覆盖率
  • 信心

在项目和业务中,产品风险、缺陷、测试和覆盖率可以,且通常以特定的方式进行度量和汇报。如果这些度量数据和测试计划中定义的出口准则相关,他们可以作为判断测试工作是否完成的客观标准。信心的度量可以通过调查或使用覆盖率作为替代度量,不过通常还会以主观的方式汇报信心。

与产品风险相关的度量
  • 完全覆盖的风险百分比(所有的测试都通过(Pass))
  • 部分覆盖的风险的百分比(有些测试或很多测试都没有通过)
  • 还未完全测试的风险的百分比(有些测试还没有测试完)
  • 按风险类别划分的覆盖的风险百分比
  • 在初次质量风险分析后识别的风险的百分比
与缺陷相关的度量
  • 已报告(发现)的缺陷总数对比已解决(修复)的缺陷总数
  • 失效的平均时间间隔和失效出现率
  • 按下列分类统计的缺陷数或百分比

o 特定的测试项或组件
o 根本原因
o 缺陷来源(如需求规格说明、新功能、回归等)
o 测试发布
o 引入、发现和移除缺陷的阶段
o 优先级/严重程度
o 拒绝或重复的缺陷报告

  • 从报告缺陷到修复缺陷所花的时间趋势
  • 引入了新缺陷(有时也称子缺陷)的缺陷修复数
和测试相关的度量
  • 已计划的、已详细说明(已实施)的、已运行、通过的、失败的、无法执行的和跳过不执行的
    测试总数
  • 回归测试和确认测试的状态,包括趋势和未通过的回归测试总数及未通过的确认测试总数
  • 计划的每日测试时长对比实际的每日测试时长
  • 测试环境的可用性(准备测试团队可用的测试环境占计划测试时长的百分比)
和测试覆盖率相关的度量
  • 需求和设计要素的覆盖率
  • 风险覆盖率
  • 环境/配置覆盖率
  • 代码覆盖率

重要的是测试经理要知道怎样去解读和使用覆盖率的度量,以便理解和报告测试状态。对于级别较高的测试,如系统测试、系统集成测试和验收测试,主要的测试依据通常是需求规格说明、设计规格说明、用例、用户故事、产品风险、支持环境和支持配置等工作产品。结构化的代码覆盖率度量更适用于级别较低的测试,如单元测试(如语句和分支覆盖)和组件集成测试(如接口覆盖)。测试经理可能使用代码覆盖的度量数据来衡量测试覆盖待测系统的程度,但在汇报较高级别的测试结果时,通常不会提到代码覆盖的度量。此外,测试经理应该知道即便单元测试和组件集成测试达到了结构覆盖目标的100%,缺陷和质量风险仍有待较高级别的测试来处理。

度量也可以连系到基本测试过程中的活动。这样一来,在整个测试过程中,就可以对照项目目标和测试过程本身,使用度量数据来监督测试过程本身以及达成项目目标的进展。

和监督测试计划和控制活动相关的度量
  • 风险、需求和其它测试依据要素的覆盖率
  • 缺陷发现情况
  • 计划开发测试件和执行测试用例的时长对比实际的时长
和监督测试分析活动相关的度量
  • 识别的测试条件数
  • 测试分析中发现的缺陷数(如通过使用测试依据识别风险或其它测试条件)
和监督测试设计活动相关的度量
  • 测试用例覆盖的测试条件百分比
  • 测试设计中发现的缺陷数(如通过对照测试依据开发测试)
和监督测试实施活动相关的度量
  • 测试环境配置的百分比
  • 测试数据记录加载的百分比
  • 测试用例自动化的百分比
和监督测试执行活动相关的度量
  • 执行、通过和失败的测试占已计划的测试的百分比
  • 执行(和/或通过)的测试用例覆盖的测试条件的百分比
  • 计划与实际的报告/解决的缺陷对比
  • 计划与实际达到的覆盖率的对比

监督测试进展和测试完成活动的度量包括里程碑、入口准则和出口准则(测试计划中定义和批准的)的映射,其中可能包括以下内容:

  • 计划的测试条件、测试用例或测试规约说明的数目和按测试是否通过分别统计的执行的测试条件、测试用例或测试规约说明的数目
  • 总缺陷数,通常按严重程度、优先级、目前状态、受影响的子系统或其它分类统计
  • 要求的、接受的、开展的和测试过的变更数
  • 计划成本对比实际成本
  • 计划工期对比实际工期
  • 测试里程碑的计划日期对比实际日期
  • 有关测试的项目里程碑(如代码冻结)的计划日期对比实际日期
  • 产品(质量)风险状态、通常按已缓解与未缓解的风险,主要的风险区域、测试分析后发现的新风险等分类统计
  • 由于阻塞事件或计划的变更导致的测试工作量、成本或时间损失的百分比
  • 确认和回归测试状态
和监督测试结束活动相关的度量
  • 测试执行期间已执行的、通过的、失败的、无法执行的和跳过不执行的测试用例的百分比
  • 纳入可复用的测试用例库的测试用例的百分比
  • 自动化的测试用例的百分比或计划的与实际的自动化的测试用例百分比对比
  • 并入回归测试的测试用例的百分比
  • 已解决/未解决的显著缺陷报告的百分比
  • 识别和归档的测试工作产品的百分比

另外,标准的项目管理技术,如工作分解结构,通常被用来监督测试过程。在敏捷团队中,测试是燃尽图上用户故事进展的一部分。使用精益管理技术时,测试进展以一系列故事为基础,通常通过用户故事卡在看板图上移动的状态来监督。

在给定了一组度量标准后,度量数据可以通过口头陈述、在表格中以数值的形式,或用图形来进行汇报。度量数据可以有很多用途,包括:

  • 分析,找出可从测试结果中观察到的趋势和原因
  • 汇报,将测试结果告知感兴趣的项目参与人和项目干系人
  • 控制,改变整个测试或项目的进程和监督进程纠正的结果

收集、分析和报告这些测试度量数据的适当方式取决于具体的信息需要、目标和使用这些度量数据的个人能力。另外,测试报告的具体内容也应该根据不同的读者而变化。

为了测试控制的需要,非常重要的一点是度量数据必须能够提供给测试经理有关整个测试过程(测试计划完成后)的信息,并能指导测试经理成功完成测试任务、实施测试策略和实现测试目标。因此在计划时一定要考虑到信息需要,监督时一定要包括收集任何需要的工作产品度量。需要的信息量和采集信息需要的工作量取决于各种项目因素,包括项目规模、复杂度和风险。

测试控制一定要回应测试产生的信息和项目或活动存在的不断变化的环境。例如,如果动态测试在某些认为不可能有很多缺陷的区域发现了缺陷群,又如由于测试开始时间延迟导致测试执行周期缩短,则必须对风险分析和计划作出修改。这么做可能需要对测试优先级重新设定和对剩余的测试执行工作重新进行分配。

如果通过测试进展报告发现与测试计划出现了偏差,则应执行测试控制。测试控制的目的是为项目和/或测试重新定向到更可能取得成功的方向。当项目的控制工作取决于测试结果或受测试结果影响时,需要考虑以下内容:

  • 修改质量风险分析、测试优先级和/或测试计划
  • 增加资源或增加项目或测试工作量
  • 推迟发布日期
  • 放松或加强测试出口准则
  • 改变项目的范围(功能或非功能)

实施这些内容通常需要项目或业务干系人之间达成共识,并且取得项目或业务经理的同意。

测试报告中发布的信息应该大部分取决于目标读者,如项目管理人员或业务管理人员的信息需要。项目经理最可能感兴趣的是关于缺陷的详细信息,而业务经理最关注的可能是产品风险的状态。

2018-12-12 13:34:56 csbmk_com 阅读数 91
  • 大规模敏捷需求管理

    课程介绍一个具有操作性的大规模敏捷需求管理方案。这个方案平衡需求运作的灵活性和规律。方案包涵大型需求管理各环节,从需求价值分析需求,决策、可视化、度量、验证、等。如果你团队或组织面临需求管理的挑战,不妨听听这个课程,让我们协助你团队建立良好的需求管理习惯持续改进。

    5854 人正在学习 去看看 CSDN讲师

当今世上软件类型各式各样,项目做得也是百花齐放、千疮百孔。故我们推出软件成本度量进阶系列文章,分层次去应对这繁花的软件世界。

首先说明一下软件成本度量的意义或目的及国内支撑的标准和方法。

一、软件成本度量是软件项目实施的重要步骤,适用于软件预算申报、审查、采购、审计、后评价人员,软件项目开发、测试人员,软件质量保证人员以及第三方评估测试人员。

二、软件成本度量的权威标准:行业标准SJ/T 11463-2013《软件研发成本度量规范》和国家标准GB/T 32911-2016《软件测试成本度量规范》

三、标准测算方法:功能点生产率人月费率=成本

功能点(单位:功能点数) * 生产率(单位:小时/功能点) = 工作量(单位:小时)

工作量/8/22(单位:人月【每天8小时、每月22天】)*人月费率(单位:万/人月) = 成本(单位:万)

生产率和人月费率数据来源:中国电子技术标准化研究院和北京软件造价评估技术创新联盟联合发布。

从标准的测算方法很容易发现,接下来只要我们能够获得软件的功能点数就可能得出我们想要的软件成本。

注:以上说明是针对有一定相关工作经验或参加过软件工程造价师认证培训课程的学员进行的说明,还有较多的细节不能进行一一的解释,如果想了解更多可报名参加软件工程造价师培训。后续是实战经验的不断进阶,所以会默认给有基础的朋友分享经验和讨论学习。

第一层、基础软件&基础评估

「软件成本度量」的第一层心法,熟知标准和度量模型、掌握并运用方法、熟悉评估流程、熟悉公司业务,悟性高者2年可成,差一点的2-4年才能练成。

在这里插入图片描述

软件成本度量业务流程图,做事一定要以目标结果为导向,作为计数人员在做成本度量前一定要知道业务流程,熟悉业务流程可以降低沟通成本、增加评估效率。

在这里插入图片描述

软件成本度量计数流程图-熟记此图,定会功力大增。

在这里插入图片描述

举例:XX门户网站、XX管理系统
  评估文档:完整的需求说明书
  计数类型:新建系统
  用户:互联网用户、操作员、管理员等
  项目特征:项目完成、政府行业、北京地区

在这里插入图片描述

评估结果呈现:

在这里插入图片描述

如今世上软件大拿层出不穷,行业架构不断优化调整,软件系统也是根据业务需要变化多端…….

下篇我们为大家分享:软件成本度量进阶系列之增强开发、中间系统评估!敬请期待……

(作者 李长秋 北京软件造价评估技术创新联盟初级咨询师)

2007-08-22 14:19:00 sjzwl 阅读数 1233
  • 大规模敏捷需求管理

    课程介绍一个具有操作性的大规模敏捷需求管理方案。这个方案平衡需求运作的灵活性和规律。方案包涵大型需求管理各环节,从需求价值分析需求,决策、可视化、度量、验证、等。如果你团队或组织面临需求管理的挑战,不妨听听这个课程,让我们协助你团队建立良好的需求管理习惯持续改进。

    5854 人正在学习 去看看 CSDN讲师

      软件度量(software measurement)是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程,目的在于对此加以理解、预测、评估、控制和改善。没有软件度量,就不能从软件开发的暗箱中跳将出来。通过软件度量可以改进软件开发过程,促进项目成功,开发高质量的软件产品。度量取向是软件开发诸多事项的横断面,包括顾客满意度度量、质量度量、项目度量、以及品牌资产度量、知识产权价值度量,等等。度量取向要依靠事实、数据、原理、法则;其方法是测试、审核、调查;其工具是统计、图表、数字、模型;其标准是量化的指标。

一、软件度量的发展历程

      如Lemmerich所言, 测量在科学领域有悠久的历史[116]。相对早在1889年就定义好了度量单位~米的长度测量[116],温度的度量复杂的多。
Fahrenheit和Celsius分别在1714年和1742年提出了基于某固定点间隔递增等级的温度度量方法。Celsius将100度和0度之间分为100个等份。但问题是一直不能唯一确定50摄氏度。而且长度的测量总是一个比例尺度,但是温度可能用间隔( 摄氏/华氏温度表) 或者比例尺度(开氏温度)来衡量。

      今天,计算机在我们生活的每个领域几乎都扮演了非常重要的角色。在计算机上运行的软件也越来越重要。因此,可预测、可重复、准确地控制软件开发过程和软件产品已经非常重要。软件度量就是衡量软件品质的一种手段。
  软件度量或者说软件工程度量领域是一个在过去30多年研究非常活跃的软件工程领域。软件度量(software measurement)和软件量度(software metrics)一样非常有名(译者注:为了区分,译者将software measurement和software metrics分别译成软件度量和软件量度,其实他们都可以表示软件度量)。但目前学界还没有明确这两个术语的区别。参照测量理论[159]的相关术语,我们采用软件度量(software measurement)。从文献上看,这两个术语是同义词。量度(metric)在这里不作度量空间理解,它理解为:度量是客观对象到数字对象的同态映射。同态映射包括所有关系和结构映射。用另一句话说,软件品质和软件度量成直对关系。这是度量和软件度量的根本理念。

      软件度量研究主要分为两个阵营:一部分认为软件可以度量,一部分认为软件无法通过度量分析。无论如何,研究主流是关心软件的品质和认为软件需要定量化度量。目前有超过上千种软件度量方法被软件研究人员及从业人员提出,并且到今天有超过5000份论文出版发表。

二、简单软件度量流程图


三、软件度量三维度

      软件度量能够为项目管理者提供有关项目的各种重要信息,其实质是根据一定规则,将数字或符号赋予系统、构件、过程或者质量等实体的特定属性,即对实体属性的量化表示,从而能够清楚地理解该实体。软件度量贯穿整个软件开发生命周期,是软件开发过程中进行理解、预测、评估、控制和改善的重要载体。软件质量度量建立在度量数学理论基础之上。软件度量包括3个维度,即项目度量、产品度量和过程度量,具体情况如表-1所示。

四、为什么需要软件度量 

  在软件开发中,软件度量的根本目的是为了管理的需要。利用度量来改进软件过程。人们是无法管理不能度量的事物。在软件开发的历史中,我们可以意识到,在60年代末期的大型软件所面临的软件危机反映了软件开发中管理的重要性。而对于管理层人员来说:没有对软件过程的可见度就无法管理;而没有对见到的事物有适当的度量或适当的准则去判断、评估和决策,也无法进行优秀的管理。我们说软件工程的方法论主要在提供可见度方面下工夫。但仅仅是方法论的提高并不能使其成为工程学科。这就需要使用度量。度量是一种可用于决策的可比较的对象。度量已知的事物是为了进行跟踪和评估。对于未知的事物,度量则用于预测。本专题将讨论软件度量的一些基本问题。但应认识到软件度量的成果是非常初步的,还需要大量工作才可能真正地做到实用化,但它的实用化成就将对软件的高质量和高速发展有不可估量的影响。那么, 一、什么是度量呢? 1、度量概念:度量存在于左右我们生活的很多系统的核心之中。在经济领域,度量决定着价格和付款的增加;在雷达系统中,度量使我们能透过云层探测到飞机;在医疗系统中,度量使得能够诊断某些特殊疾病;在天气预测系统中,度量是天气预报的基础;没有度量,技术的发展根本无法进行。度量的正式定义是: 度量 是指在现实的世界中,把数字或符号指定给实体的某一属性, 以便以这种方式来根据已明确的规则来描述它们.

   因此,度量关注的是获取关于实体属性的信息。一个实体可以是一个实物,如人或房间;或者是一个事件,如旅行;或软件项目的测试阶段。属性是我们所关注的实体的特征或特性,如血压的高度(人)、时间(测试阶段)、范围或颜色(房间)、花销(旅行) 等。因此,说"度量事物"或"度量属性"的说法是不完全正确的;应该说"度量事物的属性"。"度量房间"的说法是模糊的;我们可以说度量它的长度、范围和温度等。同样说"度量温度"的说法也是模糊的,应该说:我们度量的是某一特定地理位置和特定情况下的温度。

2、工程学科需要度量软件工程要的是有模型和理论支持的方法。
  如在设计电路的时候我们应用欧姆定律。这个定律描述了电路中电阻、电流和电压三者之间的关系。但是这些理论已超出了一般意义上的科学方法的范畴,在这种范畴里最基本的东西是度量。度量除了在发展一个理论的过程中起作用外,我们使用度量并应用它们。因此设计一个特定电流和电阻的电路时我们就知道需要多大的电压。

  如果没有度量,我们很难想象关于电子、机械、及普通工程的定律能得到发展。但事实上现在在软件工程的主流里度量却被忽略了。

  现在的情况是:
  ■当我们在设计和开发软件产品的时候,我们并未能制定出度量的目标。例如:我们保证说我们将使用户界面友好、可靠、易于维护;而并未使用度量的术语来详细说明它们的具体含义。Gilb曾经说过:所谓模糊目标定理,就是没有明确目标的项目将不能明确地达到它的目标。
  ■我们未能对构成软件项目实际费用的各个不同的部分进行有效的度量。譬如:通常我们并不知道,和测试阶段相比,设计阶段花费时间多大。
  ■我们并未试图使我们开发的产品的各种质量合格。因此我们未能使用术语(如:在一段时间里使用故障的可能性、把产品安装到新环境中需花费的工作量等)向潜在的用户说明产品的可靠性很高。
  ■我们总是试图说服自己使用另一种新的革新的开发技术和方法进行软件开发

      事实上,我们在软件度量方面做的工作很少很少,而且所作的度量方面的工作也与一般科学意义上的度量相分离。我们经常会看到诸如此类的话:"软件的费用有80%花费在维护上。"或"软件每一千行程序中平均有55个Bugs。"。但是这些话并没有告诉我们这样的结果是怎样产生的、试验是怎样设计、执行的、度量的是那个实体、及错误的框架是什么等等。没有这些东西,我们就不能在我们自己的环境中客观地进行反复度量,重现度量的结果以获得与工业标准的真实比较。因此,归因于度量不充分的问题的产生是由于缺乏严格的度量方法造成的。
      除了传统的对计算机硬件的性能进行度量外,对算法的复杂性的度量一直是计算机科学的重要组成部分。但是,这种度量方法只适用于小程序,而对大型、复杂的软件来说它却无能为力了。这就属于软件工程的范畴了。如果我们不承认度量将会一个更重要的作用的话,软件危机将在随后的几年里依然存在
 
五、软件度量工具

      随着软件定量方法(如:软件度量)的重要性不断增加,市场上出现了许多度量工具。然而,度量工具目前还是很混乱。因为没有统一的度量标准规范,每种工具发明商家都是按照他们自己的软件度量规范。文献[44]对度量工具做了好的综述。Daich等根据分类学把度量工具分成了以下几种:

      ● 通用度量工具;
      ● 小生境度量工具(Niche Metrics Tool);
      ● 静态分析;
      ● 源代码静态分析;
      ● 规模度量

六、软件度量的目标

  软件开发正在经受一场危机。费用超支(特别是在维护阶段的花费太大)、生产率低下、 以及质量不高等问题正困扰着它。简言之,软件开发经常处于失控状态。软件之所以失控是因为没有度量。Tom Demarco曾经说过:"没有度量就不能控制。"这种说法是好的,但不完全。并不能说为了获得控制必须进行度量。度量活动必须有明确的目标或目的,而正是这决定着我们选择哪种属性和实体进行度量。这个目标与软件开发、使用时所涉及的人的层次有关。
以下主要从管理者和软件工程师两种角度来考虑,为了达到各种目标所要进行的度量工作。

      ●对管理者而言:


  1.需要度量软件开发过程中的不同阶段的费用。
  例如:度量开发整个软件系统的费用(包括从需求分析阶段到发布之后的维护阶段)。必须清楚这个费用以决定在保证一定的利润的情况下的价格。

  2.为了决定付给不同的开发小组的费用,需要度量不同小组职员的生产率。
  3.为了对不同的项目进行比较、对将来的项目进行预测、建立基线以及设定合理的改进目标等,需要度量开发的产品的质量。

  4.需要决定项目的度量目标。例如:应达到多大的测试覆盖率、系统最后的可靠性应有多大等。

  5.为了找出是什么因素影响着费用和生产率,需要反复测试某一特定过程和资源的属性。

  6.需要度量和估计不同软件工程方法和工具的效用,以便决定是否有必要把它们引入到公司中。

  ●对软件工程师而言:

  1.需要制定过程度量以监视不断演进的系统。这包括设计过程中的改动、在不同的回顾或测试阶段发现的错误等等。

  2.需使用严格的度量的术语来指定对软件质量和性能的要求,以便使这些要求是可测试的。例如:系统必须"可靠",可用如下的更具体 的文字加以描述:"平均错误时间必须大于15个CPU时间片。"

  3.为了合格需要度量产品和过程的属性。例如:看一个产品是否合格要看产品的一些可度量的特性如"β测试阶段少于20个错误。","每个模块的代码行不超过100行。",和开发过程的一些属性如"单元测试必须覆盖90%以上的用例。"等。

  4.需要度量当前已存在的产品和过程的属性以便预测将来的产品。例如:

  (1).通过度量软件规格说明书的大小来预测目标? 的大小。
  (2).通过度量设计文档的结构特性来预测将来维护的"盲点"。
  (3).通过度量测试阶段的软件的可靠性来预测软件今后操作、运行的可靠性。

  研究上面我们列出的度量的目标和活动我们可以发现:软件度量的目标可大致 概括为两类。

  其一,我们使用度量来进行估计。这使得我们可以同步地跟踪一个特定的软件项目 。
  其二,我们应用度量来预测项目的一些重要的特性。但是,值得指出的是我们不能 过分夸大这些预测。因为它们并不是完全正确的。软件度量得到也仅仅是预测而已。有些人甚至认为只要使用合适的模型和工具,所获得的预测可以精确到只需使用极少的其他度量(甚至根本就不用使用度量)。事实上,这种期望是不现实的。

七、软件度量的方法体系

      项目度量

      项目度量是针对软件开发项目的特定度量,目的在于度量项目规模、项目成本、项目进度、顾客满意度等,辅助项目管理进行项目控制。

      规模度量

      软件开发项目规模度量(size measurement)是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。规模度量是软件项目失败的重要原因之一。一个好的规模度量模型可以解决这一问题。有效的软件规模度量是成功项目的核心要素:基于有效的软件规模度量可以策划合理的项目计划,合理的项目计划有助于有效地管理项目。规模度量的要点在于:由开发现场的项目成员进行估算;灵活运用实际开发作业数据;杜绝盲目迎合顾客需求的“交期逆推法”。

      软件规模度量有助于软件开发团队准确把握开发时间、费用分布以及缺陷密度等等。软件规模的估算方法有很多种,如:功能点分析(FPA:function points analysis)、代码行(LOC:lines of code)、德尔菲法(Delphi technique)、COCOMO模型、特征点(feature point)、对象点(object point)、3-D功能点(3-D function points)、Bang度量(DeMarco's bang metric)、模糊逻辑(fuzzy logic)、标准构件法(standard component)等,这些方法不断细化为更多具体的方法。

      成本度量

      软件开发成本度量主要指软件开发项目所需的财务性成本的估算。主要方法如下:

      类比估算法。类比估算法是通过比较已完成的类似项目系统来估算成本,适合评估一些与历史项目在应用领域、环境和复杂度方面相似的项目。其约束条件在于必须存在类似的具有可比性的软件开发系统,估算结果的精确度依赖于历史项目数据的完整性、准确度以及现行项目与历史项目的近似程度。

      细分估算法。细分估算法是将整个项目系统分解成若干个小系统,逐个估算成本,然后合计起来作为整个项目的估算成本。细分估算法通过逐渐细化的方式对每个小系统进行详细的估算,可能获得贴近实际的估算成本。其难点在于,难以把握各小系统整合为大系统的整合成本。

      周期估算法。周期估算法是按软件开发周期进行划分,估算各个阶段的成本,然后进行汇总合计。周期估算法基于软件工程理论对软件开发的各个阶段进行估算,很适合瀑布型软件开发方法,但是需要估算者对软件工程各个阶段的作业量和相互间的比例具有相当的了解。

      顾客满意度度量

      顾客满意是软件开发项目的主要目的之一,而顾客满意目标要得以实现,需要建立顾客满意度度量体系和指标对顾客满意度进行度量。顾客满意度指标(CSI:customer satisfaction index)以顾客满意研究为基础,对顾客满意度加以界定和描述。项目顾客满意度量的要点在于:确定各类信息、数据、资料来源的准确性、客观性、合理性、有效性,并以此建立产品、服务质量的衡量指标和标准。企业顾客满意度度量的标准会因为各企业的经营理念、经营战略、经营重点、价值取向、顾客满意度调查结果等因素而有所不同。比如:NEC于2002年12月开始实施的CSMP 活动的度量尺度包括共感性、诚实性、革新性、确实性和迅速性,其中,将共感性和诚实性作为CS活动的核心姿态,而将革新性、确实性和迅速性作为提供商品和服务中不可或缺的尺度。每个尺度包括两个要素,各要素包括两个项目,共计5大尺度、10个要素和20个项目。例如,共感性这一尺度包括“了解顾客的期待”、“从顾客的立场考虑问题”这两个要素;“了解顾客的期待”这一要素又包括“不仅仅能胜任目前的工作还能意识到为顾客提供价值而专心投入”、“对顾客的期望不是囫囵吞枣而是根据顾客的立场和状况来思考‘顾客到底需要什么’并加以应对”这两个项目。

      美国专家斯蒂芬(Stephen H.Kan)在《软件质量工程的度量与模型》(Metrics and Models in Software Quality Engineering)中认为,企业的顾客满意度要素如表7-1所示:

顾客满意度要素 顾客满意度要素的内容
技术解决方案 质量、可靠性、有效性、易用性、价格、安装、新技术
支持与维护 灵活性、易达性、产品知识
市场营销 解决方案、接触点、信息
管理 购买流程、请求手续、保证期限、注意事项
交付 准时、准确、交付后过程
企业形象 技术领导、财务稳定性、执行印象

表7-1 顾客满意度要素及其内容

      作为企业的顾客满意度的基本构成单位,项目的顾客满意度会受到项目要素的影响,主要包括:开发的软件产品、开发文档、项目进度以及交期、技术水平、沟通能力、运用维护等等。具体而言,可以细分为如表7-2所示的度量要素,并根据这些要素进行度量。

顾客满意度项目 顾客满意度度量要素
软件产品 功能性、可靠性、易用性、效率性、可维护性、可移植性
开发文档 文档的构成、质量、外观、图表以及索引、用语
项目进度以及交期 交期的根据、进度迟延情况下的应对、进展报告
技术水平 项目组的技术水平、项目组的提案能力、项目组的问题解决能力
沟通能力 事件记录、式样确认、Q&A
运用维护 支持、问题发生时的应对速度、问题解决能力

表7-2顾客满意度项目度量要素

      产品度量

      软件质量的生命周期及其度量
      软件产品度量用于对软件产品进行评价,并在此基础之上推进产品设计、产品制造和产品服务优化。软件产品的度量实质上是软件质量的度量,而软件的质量度量与其质量的周期密切相关,如图7-1所示:

      软件质量度量模型

      软件产品的度量主要针对作为软件开发成果的软件产品的质量而言,独立于其过程。软件的质量由一系列质量要素组成,每一个质量要素又由一些衡量标准组成,每个衡量标准又由一些量度标准加以定量刻划。质量度量贯穿于软件工程的全过程以及软件交付之后,在软件交付之前的度量主要包括程序复杂性、模块的有效性和总的程序规模,在软件交付之后的度量则主要包括残存的缺陷数和系统的可维护性方面。一般情况下,可以将软件质量特性定义成分层模型。勃姆(Barry W. Boehm)在《软件风险管理》(Software Risk Management)中第一次提出了软件质量度量的层次模型。而麦考尔(McCall)等人将软件质量分解至能够度量的层次,提出FCM 3层模型(参见表5-13):软件质量要素(factor)、衡量标准(criteria)和量度标准(metrics),包括11个标准,分为产品操作(product operation)、产品修正(product revision)和产品转移(product transition)。ISO 9126将软件质量总结为6大特性,每个特性包括一系列副特性,其软件质量模型包括3层,即高层:软件质量需求评价准则(SQRC);中层:软件质量设计评价准则(SQDC);低层:软件质量度量评价准则(SQMC)。

层 级 名 称 内 容
第一层 质量要素:描述和评价软件质量的一组属性 功能性、可靠性、易用性、效率性、可维护性、可移植性等质量特性以及将质量特性细化产生的副特性
第二层 衡量标准: 衡量标准的组合反映某一软件质量要素 精确性、稳健性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、文件完备性等
第三层 量度标准:
可由各使用单位自定义
根据软件的需求分析、概要设计、详细设计、编码、测试、确认、维护与使用等阶段,针对每一个阶段制定问卷表,以此实现软件开发过程的质量度量

表7-3 软件质量度量FCM模型

      凯悦(Lawrence E. Hyatt)和罗森贝克(Linda H. Rosenberg)在《识别项目风险以及评价软件质量的软件质量模型与度量》(A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality)中比较了这3种最常用的软件质量模型,其基本情况如表5-14所示。

度量标准/目标 麦 考 尔 勃 姆 ISO 9126
正确性(Correctness) X X 可维护性
可靠性(Reliability) X X X
完整性(Integrity) X X  
可用性(Usability) X X X
效率性(Efficiency) X X X
可维护性(Maintainability) X X X
可测试性(Testability) X   可维护性
互操作性(Interoperability) X    
适应性(Flexibility) X X  
可重用性(Reusability) X X  
可移植性(Portability) X X X
明确性(Clarity)   X  
可变更性(Modifiability)   X 可维护性
文档化(Documentation)   X  
恢复力(Resilience)   X  
易懂性(Understandability)   X  
有效性(Validity)   X 可维护性
功能性(Functionality)     X
普遍性(Generality)   X  
经济性(Economy)   X  


表7-4 3种软件质量模型之比较 

      软件质量度量方法
      软件质量度量方法比较多,例如:(1)Halstead复杂性度量法,基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大,程序结构就越复杂。(2)McCabe复杂性度量法,其基本思想是程序的复杂性很大程度上取决于程序控制流的复杂性,单一的顺序程序结构最简单,循环和选择所构成的环路越多,程序就越复杂。


      过程度量

      软件过程性能
      过程度量是对软件开发过程的各个方面进行度量,目的在于预测过程的未来性能,减少过程结果的偏差,对软件过程的行为进行目标管理,为过程控制、过程评价持续改善提供定量性基础。过程度量与软件开发流程密切相关,具有战略性意义。软件过程质量的好坏会直接影响软件产品质量的好坏,度量并评估过程、提高过程成熟度可以改进产品质量。相反,度量并评估软件产品质量会为提高软件过程质量提供必要的反馈和依据。过程度量与软件过程的成熟度密切相关,其度量模型如图7-2所示:

图7-2 软件过程性能的度量模型

      软件过程管理中的过程度量
      弗罗哈克(William A.Florac)、帕克(Robert E.Park)和卡尔顿(Anita D.Carleton)在《实用软件度量:过程管理和改善之度量》(Practical Software Measurement:Measuring for Process Management and Improvement)中描述了过程管理和项目管理的关系。认为软件项目团队生产产品基于三大要素:产品需求、项目计划和已定义软件过程。度量数据在项目管理中将被用来:(1)识别和描述需求,(2)准备能够实现目标的计划,(3)执行计划,(4)跟踪基于项目计划目标的工作执行状态和进展。而过程管理也能使用相同的数据和相关度量来控制和改善软件过程本身。这就意味着,软件组织能使用建构和维持度量活动的共同框架来为过程管理和项目管理两大管理功能提供数据。

      软件过程管理包括定义过程、计划度量、执行软件过程、应用度量、控制过程和改善过程,其中计划度量和应用度量是软件过程管理中的重要步骤,也是软件过程度量的核心内容。计划度量建立在对已定义软件过程的理解之上,产品、过程、资源的相关事项和属性已经被识别,收集和使用度量以进行过程性能跟踪的规定都被集成到软件过程之中。应用度量通过过程度量将执行软件过程所获得的数据,以及通过产品度量将产品相关数据用来控制和改善软件过程。

      软件过程度量的内容
      软件过程度量主要包括三大方面的内容,一是成熟度度量(maturity metrics),主要包括组织度量、资源度量、培训度量、文档标准化度量、数据管理与分析度量、过程质量度量等等;二是管理度量(management metrics),主要包括项目管理度量(如里程碑管理度量、风险度量、作业流程度量、控制度量、管理数据库度量等)、质量管理度量(如质量审查度量、质量测试度量、质量保证度量等)、配置管理度量(如式样变更控制度量、版本管理控制度量等);三是生命周期度量(life cycle metrics),主要包括问题定义度量、需求分析度量、设计度量、制造度量、维护度量等。

      软件过程度量流程
      软件过程的度量,需要按照已经明确定义的度量流程加以实施,这样能使软件过程度量作业具有可控制性和可跟踪性,从而提高度量的有效性。软件过程度量的一般流程主要包括:确认过程问题;收集过程数据;分析过程数据;解释过程数据;汇报过程分析;提出过程建议;实施过程行动;实施监督和控制。这一度量过程的流程质量能保证软件过程度量获得有关软件过程的数据和问题,并进而对软件过程实施改善。 
 

本来想发一篇关于"功能点"的文章,不过想来想去还是这个比较好 :)
有需要"功能点快速参考手册"的朋友请留下E-MAIL,我会发给大家的.

2017-08-06 11:35:08 ambrosio1986 阅读数 187
  • 大规模敏捷需求管理

    课程介绍一个具有操作性的大规模敏捷需求管理方案。这个方案平衡需求运作的灵活性和规律。方案包涵大型需求管理各环节,从需求价值分析需求,决策、可视化、度量、验证、等。如果你团队或组织面临需求管理的挑战,不妨听听这个课程,让我们协助你团队建立良好的需求管理习惯持续改进。

    5854 人正在学习 去看看 CSDN讲师

1、度量的重要性

        度量是衡量测试过程和测试结果的主要依据,也是贯穿整个测试为管理层提供决策的重要依据,只有详实准确的测试数据指标,才能准确的反映出测试问题和风险,没有度量的软件测试,无法给软件产品相关的各方干系人提供信息,也无法为软件上线投产后提供各种风险缓释措施,会为整个生产埋下重大风险。

2、度量指标

        度量本身一般是以指标的形式体现的,而指标一般可以划分为管理指标与技术指标,其中技术指标主要是体现在性能测试方面。2.1、管理指标

        管理指标按照测试阶段划分主要分为过程度量指标与结果度量指标两种,过程度量指标,主要是用来指导测试行为,揭露过程风险,为管理者管控整体测试提供依据。而结果度量指标,则是展示整体测试质量,为是否能够正常投产上线提供依据,且与考核息息相关,也用于指导后续测试的开展。

        常见的过程度量指标如下:

        A、总体案例执行情况;B、本日案例执行情况;C、正反案例占比情况;D、整体缺陷解决情况;E、缺陷处理方情况;F、缺陷归属方情况

        测试过程度量指标往往体现在测试项目的日报和周报之中。

        常见的结果度量指标如下:

        A、案例设计充分性;B、缺陷逃逸率;C、缺陷解决效率;D、缺陷重现率;E、测试计划完整性;F、测试按计划执行率;G、数据安全指标;H、环境稳定性指标。

        测试结果度量指标往往体现在测试报告和整体考核报告中。

2.2、技术指标

        技术指标往往应用于性能测试领域,用于指导性能测试方案编制和案例执行,该指标主要分为:性能容量(开放平台)、性能容量(主机)、性能容量(数据线系统)、可用性、可维护性、可扩展性、兼容性、性能容量共8个大类,每个类别下面再细分不同的小类,然后再到各个小的指标项。笔者所在公司的性能测试体系,共有216项详细的性能测试指标。

        而常用的测试指标一般如下:

        A、响应时间;B、并发用户数;C、内存利用率;D、CPU利用率;E、负载策略有效性;F、超时有效性;G、流控有效性;H、AP横向纵向扩展有效性;I、MIPS/TPS;K、高峰业务量

2.3、报表工具

        如果度量指标由人工手工获取,编制,则度量的成本将无限增大,而机械繁重的工作,也会让获取人员产生极强的厌烦心理,长期可能故意有倾向性的破坏度量指标,得不偿失,故在采用详细的度量手段的同时,一定要有功能强大的报表工具。目前市场上很多测试管理工具自身就可以提供十分强大的报表功能,有的甚至开放API供企业自行开发相应的报表,例如笔者所在公司所使用的测试案例管理工具QC,基本就可以满足管理层所关心的各个维度、不同主题的数据统计需求,在此基础上可以制作内容详实,数据更新实时的测试日报,而基于这些报表数据,测试经理可以分析出相应的问题风险,及时上报,及时考虑风险应对措施,从而有效改变测试实施策略,有效控制整个测试过程的质量。    
2018-12-12 13:40:11 weixin_43768737 阅读数 32
  • 大规模敏捷需求管理

    课程介绍一个具有操作性的大规模敏捷需求管理方案。这个方案平衡需求运作的灵活性和规律。方案包涵大型需求管理各环节,从需求价值分析需求,决策、可视化、度量、验证、等。如果你团队或组织面临需求管理的挑战,不妨听听这个课程,让我们协助你团队建立良好的需求管理习惯持续改进。

    5854 人正在学习 去看看 CSDN讲师

当今世上软件类型各式各样,项目做得也是百花齐放、千疮百孔。故我们推出软件成本度量进阶系列文章,分层次去应对这繁花的软件世界。

首先说明一下软件成本度量的意义或目的及国内支撑的标准和方法。

一、软件成本度量是软件项目实施的重要步骤,适用于软件预算申报、审查、采购、审计、后评价人员,软件项目开发、测试人员,软件质量保证人员以及第三方评估测试人员。

二、软件成本度量的权威标准:行业标准SJ/T 11463-2013《软件研发成本度量规范》和国家标准GB/T 32911-2016《软件测试成本度量规范》

三、标准测算方法:功能点生产率人月费率=成本

功能点(单位:功能点数) * 生产率(单位:小时/功能点) = 工作量(单位:小时)

工作量/8/22(单位:人月【每天8小时、每月22天】)*人月费率(单位:万/人月) = 成本(单位:万)

生产率和人月费率数据来源:中国电子技术标准化研究院和北京软件造价评估技术创新联盟联合发布。

从标准的测算方法很容易发现,接下来只要我们能够获得软件的功能点数就可能得出我们想要的软件成本。

注:以上说明是针对有一定相关工作经验或参加过软件工程造价师认证培训课程的学员进行的说明,还有较多的细节不能进行一一的解释,如果想了解更多可报名参加软件工程造价师培训。后续是实战经验的不断进阶,所以会默认给有基础的朋友分享经验和讨论学习。

第一层、基础软件&基础评估

「软件成本度量」的第一层心法,熟知标准和度量模型、掌握并运用方法、熟悉评估流程、熟悉公司业务,悟性高者2年可成,差一点的2-4年才能练成。

在这里插入图片描述

软件成本度量业务流程图,做事一定要以目标结果为导向,作为计数人员在做成本度量前一定要知道业务流程,熟悉业务流程可以降低沟通成本、增加评估效率。

在这里插入图片描述

软件成本度量计数流程图-熟记此图,定会功力大增。

在这里插入图片描述

举例:XX门户网站、XX管理系统
  评估文档:完整的需求说明书
  计数类型:新建系统
  用户:互联网用户、操作员、管理员等
  项目特征:项目完成、政府行业、北京地区

在这里插入图片描述

评估结果呈现:

在这里插入图片描述

如今世上软件大拿层出不穷,行业架构不断优化调整,软件系统也是根据业务需要变化多端…….

下篇我们为大家分享:软件成本度量进阶系列之增强开发、中间系统评估!敬请期待……

(作者 李长秋 北京软件造价评估技术创新联盟初级咨询师)

没有更多推荐了,返回首页