软件度量总结(精)

软件度量总结这次总结的结构比较简单,就是按照五个章节分别阐述了自己的理解。

一.软件度量的应用范围。

经过这一阶段的学习,我认为想要明白软件度量,首先要分清度量和测量的区别。

度量具有前置性,它提供了一种定量研究软件问题的方法;测量具有实时性或后置性,主要集中在给度量提供数据或者处理数据的方法上。

由于软件工程强烈的不确定性,使得软件工程的精确测量困难重重,但软件度量主要研究的是可能性的规律,通过概率和统计学的研究,寻找事物内在的规律。

其并不具备 1+1=2的特征, 而是研究在多大可能性上这个结论是合理的,因为软件的主体是人,具有概率属性,设备和材料容易度量,但人很难度量。

软件度量的主要作用是评估状况、跟踪进展情况、评价产品有效性和改进设计和过程的质量。

定性分析可以提供迅速地判断能力,但定性分析终究需要定量分析的验证与支持,否则其结果很可能成为无目之本,出现错误。

软件度量的方法体系主要包括 5个方面:1. 项目度量,目的在于度量项目规模、成本、进度、顾客满意度等,辅助项目管理进行项目控制; 2. 规模度量,主要依靠经验和经验的模型,是决定项目成败的重要原因之一,是估算工作量、成本预算及策划项目进度的基础; 3. 成本度量, 4。

产品度量,实质上是软件质量的度量,软件的质量由一系列质量要素组成,每个质量要素又由一些衡量标准组成,主要肚量方法是McCabe 复杂性度量法; 5,过程度量,对软件开发过程的个各方面进行度量,目的在于预测过程的未来属性,减少结果的偏差,主要包括成熟度度量(例如 CMMI,GJB5000A、管理度量(主要包括里程碑管理、风险度量等项目管理度量,审查度量、质量保证度量等质量管理度量,变更控制、版本管理度量等配置管理度量、生命周期度量三个大的方面。

不同层次的人员对软件度量有不同的需求。

高级管理人员,如 CEO 、 COO ,关注点在上市时间、客户满意度、费用的节省等商业策略的组成部分上;中级管理层,如部门经理、总监等,则主要关注生产力、成本控制、效率等,他们更多的是着眼于总体的性能,交付情况以及产品的运行状态等,而不是项目每天完成的情况;项目管理层对度量的需求则是准确估计和控制软件产品,主要考虑通过每周的对比评测、研究进展,以确保项目开发方向的正确性,或者主动捕捉测量点,由度量分析师发展成一种模型,预测项目未来的结果。

二.软件测量基础。

软件测量是经典测量科学基础上的具体应用,为了使软件度量真正发挥作用,必须掌握测量的基础知识。

软件度量不能用现成的公式进行计算,需要根据自己的实际情况建立模型,并通过历史数据来定义参数。

首先,测量的表示理论。

人们一般习惯从比较中获得对事物的理解,例如二元关系、三元关系中谁比谁大等,而这种关系可以映射到数学世界中,由此可以把测量定义为从经验世界到关系世界的一种映射,把度量定义为为了描述实体的某种属性,而为这个实体赋予的数字或者符号。

比如为了描述人的年龄,将这个人从出生到现在的所经历的年数作为年龄属性赋予这个人。

第二,测量和模型。

模型是对显示的抽象,除去了实现的细枝末节,使我们可以我们从特定的角度看待实体和概念。

测量可以分为直接测量和间接测量两种,而一个预测系统通常由一个数学模型和一组预测规程组成,其中,预测规程的作用是确定预测参数并对结果进行解释。

第三,测量数据收集与分析。

良好的数据应该具有正确性、准确性、一致性的特点,并要具有合适的精度,能与特定活动或持续时间相关联,且能够重复出现。

就数据的收集而言,第一步要制订数据收集计划,然后决定测量项,根据需要选取合适的测试粒度,并确保产品处于配置控制之下,必须了解对产品的哪些版本进行测量;三.软件规模的估算与度量。

软件规模的估算与度量部分,我主要想写一下我理解的功能点估算及用例点估算的主要流程及估算过程中需要注意的问题。

在此之前先简单地描述一下传统的代码行度量,一般认为空白行和注释行不应该计算在代码行中,并把不带注释的行数缩写为 NCLOC(又称为有效代码行 ELOC, 并将注释行定义为 CLOC, 则总长度为LOC=NCLOC+ELOC,注释行的密度用 CLOC/LOC表示。

但由于所用的语言不同导致代码行不同等原因,代码行不适于作估算,更适合用作完成之后的测量。

接下来是功能点估算。

功能点估算提出的目的是使得不同国家,不同人对同样的需求估算得到的规模大小基本相同;其缺点是对需求描述的要求比较高。

在这个方法中,功能点是一个度量单元,度量所得到的值和软件的代码量没有关系,也就不再依赖于选择的编程语言。

至于功能点估算的过程,最简单地来说包括 4个步骤:①估算数据功能规模,②估算事务处理规模,③计算调整因子,④根据公式计算功能点数。

数据功能规模主要涉及系统所处理的数据文件对系统复杂性的影响,可以分为内部逻辑文件和外部接口文件两种。

事务处理规模则可以分为三种形式,即外部输入、外部输出、外部查询。

首先要对上述概念进行识别,内部逻辑文件可以描述为一个基本处理在应用程序内部维护逻辑上相关的数据块或者控制信息,其中, “ 维护” 指增删改查等操作, “ 逻辑上相关” 指仅考虑用到的或者逻辑上有关系的数据;外部接口文件可以理解为系统不进行维护的逻辑文件。

这两种文件的复杂贡献度可以分别通过数据元素类型(字段个数和记录元素类型(数据表的数目两个纬度来考虑,每个具体文件所对应的加权系数可以查询对应的复杂型矩阵来得到,最后把加权系数相加即得到这两种文件的总功能点数,即数据功能的功能点数。

这个过程中,难点在于对每个文件进行数据元素类型和记录元素类型的识别,有一系列的注意事项。

接下来是对外部输入、外部输出和外部查询的识别,外部输入可以简单地理解为用户通过系统所进行地增、删、改,其结果可以是维护了内部的数据文件,也可以是改变了系统地行为状态;外部输出可以理解为系统所作出的反映,例如显示屏上显示某些结果,或者系统行为发生某些改变;外部查询没有对数据的处理,仅仅是对已有信息的抓取。

这一部分相对容易理解,识别起来也比上面那部分容易一些,其加权系数由数据元素类型 DET (与内部逻辑文件和外部接口文件中的 DET 基本相同和参考文件类型 FTR (被事务处理的文件总数两个维度考虑,具体数值也是可以通过查询矩阵表来获得,分别得到后相加即可以得到事务处理的功能点数。

接下来需要计算值调整因子 VAF , VAF 根据非功能需求获得,不同的项目可能会根据实际情况有一些调整,然后根据公式求得 VAF 的具体值。

最后一步就是将前面两步所得的功能点相加, 再乘以调整因子,得到最终的功能点数。

由于软件工程不断向着面向对象甚至面向过程方向发展,而功能点估算仍然是结构化的估算方法, 所以出现了用例点估算。

用例点估算的方法和功能点估算原理相似,都是讲系统先按照一定的原则分割成数个部分,分别得到估算结果之后再相加得到总的结果。

用例点估算首先要明确什么是用例,我认为用例描述了一个动作序列,这些动作是系统为了响应事件而做的,其结果是产生了对发起事件的角色有价值的可见的结果。

用例点估算必须具备的基础是良好的用例图和场景描述,有了这两个基础,估算过程相对来说就很简单,也可以分为 4个基本步骤:①确定未调整功能点数,②计算复杂因子,③计算软件规模,④估算工作量。

第①个过程主要是用例角色复杂度和用例事务数的识别,角色可以是人,计算机或者组织, 关键是分清它用什么方式与系统交互,查到对应的权重,从而计算获得未平衡角色数;事物是指从用户到系统再到用户的一个“回路”,根据场景描述确定每个用例的事物数,同样查询其对应的权值之后计算得到未平衡用例数,最后这两个数值相加得到未调整功能点数。

第②步中复杂度因子的计算主要分为技术复杂度因子 TCF 和环境复杂度因子 ECF 两类,与功能点估算中调整因子的计算方法相同,对各个项目分别打分后得出两个复杂因子。

第③步,软件规模 UCP 即为技术复杂度因子 TCF ×环境复杂度因子 ECF ×软件规模UCP 。

最后根据历史数据确定每个 UCP 完成的工作量(通常为 16人时 ~30人时,与计算所得的 UCP 相乘即为开发工作量,在此之外,用例点模型将项目管理、质量保证等时间作为补充效果 SE 计算, 补充效果 SE+开发工作量就是最终的估算结果。

四.过程规划、预测与监控中的度量。

这一章主要简单地说一下对项目评估预评审技术(PERT 、原始的 CoCoMo 模型、诤值分析以及项目监控中数据分析的理解。

由于理解不是特别深刻,所以只能简单的描述一下现有的了解。

关于 PERT , 我认为最主要的就是对三个数据的评估,即乐观的 OD (不考虑效率和中断,完成任务的最小时间量、悲观的 PD (考虑各种培训、生病以及工作时间做与工作无关的事情等各种延误情况和最有可能的 ED (不是 OD 和 PD 的中间值,而是根据经验估算认为的最可能的情况。

根据这三个值得出项目的 beta 分布及其图像(使用 beta 分布而不是用正态分布的原因是人们的评估往往偏向于乐观,图中使得左右两侧面积近似相等的分割线所对应的时间即为最可能的工作量。

这种估算方法需要策划小组人员分别进行估算得到结果后,再对结果按照一定的策略进行对比分析,得到最终的估计值。

原始的 CoCoMo 模型是用于软件开发不同阶段的三个模型的集合。

基本、中间、详细这三个层次的模型分别用于对项目了解很少、明确需求、完成设计以后三个阶段,但都具有相同的形式,即 E=aSb F 。

E 是按人月计算的工作量, S 是按千行交付的原指令数目的测量规模, F 是调整因子(不同层次的模型中取不同值, a 和 b 又根据软件的三种类别(有机式、半分离式和嵌入式分别取不同的数值。

诤值分析法是为了将项目的范围偏差跟踪、进度偏差跟踪和成本偏差跟踪统一起来。

这个方法的核心是比较准确的估算出工作完成的百分比。

计划的费用 PV 是一条表示期望值的基线,代表着截止到某一时刻计划完成的工作,可以用计划消耗的费用来表示;实际的费用 AC 表示截止到某一时刻实际的成本;诤值 EV 表示截止某一时刻,实际完成的工作应该消耗的成本。

同一时刻的 EV 与 PV 的单一变量是工作量,分别是实际的工作量和计划的工作量,所以这两个值可以得出进度的偏差; AC 与 EV 的单一变量是实际的费用,分别是实际消耗的费用和计划消耗的费用,所以这两个值可以得出成本的偏差。

这是两个最重要的偏差。

五.产品设计质量度量与控制。

我认为非功能性需求是软件度量中最容易被忽略的,也最不容易被清晰掌握的部分。

在需求分析中, 常见的非功能性需求虽然都能设计感官需求、易使用性、安全性、可靠性、可维护性等方面,但对其要求的描述都只停留在定性的描述上,没有明确的度量标准。