软件度量总结

1、软件度量总结这次总结的结构比较简单，就是按照五个章节分别阐述了自己的理解。一 软件度量的应用范围。经过这一阶段的学习，我认为想要明白软件度量，首先要分清度量和测量的区 别。度量具有前置 性,它提供了一种定量研究软件问题的方法；测量具有实时性或后 置性，主要集中在给度量提供数据或者 处理数据的方法上。由于软件工程强烈的不 确定性，使得软件工程的精确测量困难重重，但软件度量主要 研究的是可能性的规律 通过概率和统计学的研究，寻找事物内在的规律。其并不具备 1+仁2的特征,而是研 究在多大可能性上这个结论是合理的，因为软件的主体是人，具有概率属性，设备和材 料容易度 量,但人很难度量。软件度量的主要

2、作用是评估状况、跟踪进展情况、评 价产品有效性和改进设计和过程 的质量。定性分析可以提供迅速地判断能力，但定 性分析终究需要定量分析的验证与支持，否则其结果很 可能成为无目之本，出现错 误。软件度量的方法体系主要包括 5个方面:1.项目度量，目的在于度量项目规模、 成本、进度、顾客满 意度等,辅助项目管理进行项目控制；2.规模度量，主要依靠经 验和经验的模型，是决定项目成败的重要 原因之一，是估算工作量、成本预算及策划 项目进度的基础；3.成本度量，4。产品度量，实质上是软件质量的度量，软件的质量 由一系列质量要素组成，每个质量要素又由一些衡量标准组成，主要肚量方法是 McCabe复杂性度量法

3、；5,过程度量，对软件开发过程的个各方面进行度量，目的在于 预测过程的未来属 性,减少结果的偏差，主要包括成熟度度量（例如CMMI, GJB5000A、管理度量（主要包括里程碑管 理、风险度量等项目管理度量，审查度 量、质量保证度量等质量管理度量，变更控制、版本管理度量等配 置管理度量、生 命周期度量三个大的方面。不同层次的人员对软件度量有不同的需求。高级管理人员 ，如CEO、C00,关 注点在上市时间、客户满意度、费用的节省等商业策略的组成部分上；中级管理层, 如部门经理、总监等，则主要关注生产 力、成本控制、效率等，他们更多的是着眼于 总体的性能，交付情况以及产品的运行状态等，而不是项目每

4、天完成的情况；项目管 理层对度量的需求则是准确估计和控制软件产品，主要考虑通过每周的对比评测、 研究进展，以确保项目开发方向的正确性，或者主动捕捉测量点，由度量分析师发展成 一种模型，预测项目未来的结果。二.软件测量基础。软件测量是经典测量科学基础上的具体应用，为了使软件度量真正发挥作用，必 须掌握测量的基础 知识。软件度量不能用现成的公式进行计算，需要根据自己的实 际情况建立模型，并通过历史数据来定义 参数。首先，测量的表示理论。人们一般习 惯从比较中获得对事物的理解，例如二元关系、三元关系中谁比谁大等，而这种关系 可以映射到数学世界中，由此可以把测量定义为从经验世界到关系世界的一种映射,把

5、度量定义为为了描述实体的某种属性，而为这个实体赋予的数字或者符号。比如 为了描述人的年 龄,将这个人从出生到现在的所经历的年数作为年龄属性赋予这个 人。第二，测量和模型。模型是对显示 的抽象，除去了实现的细枝末节，使我们可以我 们从特定的角度看待实体和概念。测量可以分为直接测量和间接测量两种，而一个预测系统通常由一个数学模型和一组预测规程组成，其中，预测规程的作用是确定预 测参数并对结果进行解释。第三，测量数据收集与分析。良好的数据应该具有正确 性、准确性、一致 性的特点，并要具有合适的精度，能与特定活动或持续时间相关联 且能够重复出现。就数据的收集而言,第一步要制订数据收集计划，然后决定测量

6、项，根据需要选取合适的测试粒度 并确保产品处于配置控制之下，必须了解对产品的哪些版本进行测量；三软件规模的估算与度量。软件规模的估算与度量部分，我主要想写一下我理解的功能点估算及用例点估 算的主要流程及估算 过程中需要注意的问题。在此之前先简单地描述一下传统的 代码行度量，一般认为空白行和注释行不应该 计算在代码行中，并把不带注释的行数 缩写为NCLOC（又称为有效代码行ELOC,并将注释行定义为CLOC,则总长度为LOC=NCLOC+ELOC,注释行的密度用CLOC/LOC表示。但由于所用的语言不同导 致代码行不同等原因，代码行不适于作估算，更适合用作完成之后的测量。接下来是功能点估算。功能

7、点估算提出的目的是使得不同国家，不同人对同样的需求估算得到的规 模大小基本相同；其缺点是对需求描述的要求比较高。在这个 方法中，功能点是一个度量单元，度量所得到的值和软件的代码量没有关系，也就不再 依赖于选择的编程语言。至于功能点估算的过程 ，最简单地来说包括4个步骤:估 算数据功能规模，估算事务处理规模，计算调整因子，根据公式计算功能点 数。 数据功能规模主要涉及系统所处理的数据文件对系统复杂性的影响，可以分为内部逻辑文件和外部接口文件两种。事务处理规模则可以分为三种形式，即外部输入、 外部输出、外部查询。首先要对上述概念 进行识别,内部逻辑文件可以描述为一个 基本处理在应用程序内部维护逻辑

8、上相关的数据块或者控制信息，其中，维护”指增删改查等操作，逻辑上相关”指仅考虑用到的或者逻辑上有关系的数据；外部接 口文件可以理解为系统不进行维护的逻辑文件。这两种文件的复杂贡献度可以分 别通过数据元素类型（字段个数和记录元素类型（数据表的数目两个纬度来考虑，每 个具体文件所对应的加权系数可以查询对应 的复杂型矩阵来得到，最后把加权系数 相加即得到这两种文件的总功能点数，即数据功能的功能点数。这个过程中，难点在 于对每个文件进行数据元素类型和记录元素类型的识别，有一系列的注意事项。接 下来是对外部输入、外部输出和外部查询的识别，外部输入可以简单地理解为用户 通过系统所进行地增、删、 改，其结果

9、可以是维护了内部的数据文件，也可以是改变 了系统地行为状态；外部输出可以理解为系统所作出的反映，例如显示屏上显示某些 结果,或者系统行为发生某些改变；外部查询没有对数据的处理，仅仅是对已有信息 的抓取。这一部分相对容易理解，识别起来也比上面那部分容易一些，其加权系数由 数据元素类型DET （与内部逻辑文件和外部接口文件中的 DET基本相同和参考文 件类型FTR （被事务处理的文件总数两个维度考虑，具体数值也是可以通过查询矩 阵表来获得，分别得到后相加即可以得到事务处理的功能点数。接下来需要计算值 调整因子VAF , VAF根据非功能需求获得，不同的项目可能会根据 实际情况有一些 调整，然后根据

10、公式求得VAF的具体值。最后一步就是将前面两步所得的功能点相 加,再乘以调整因子，得到最终的功能点数。由于软件工程不断向着面向对象甚至面向过程方向发展，而功能点估算仍然是 结构化的估算方法，所以出现了用例点估算。用例点估算的方法和功能点估算原理 相似，都是讲系统先按照一定的原则分割成数个部分，分别得到估算结果之后再相加 得到总的结果。用例点估算首先要明确什么是用例 ，我认为用例 描述了一个动作序 列，这些动作是系统为了响应事件而做的，其结果是产生了对发起事件的角色有价值 的可见的结果。用例点估算必须具备的基础是良好的用例图和场景描述，有了这两个基础，估算过程相对来说就很简单，也可以分为4个基本

11、步骤：确定未调整功能点 数，计算复杂因子，计算软件规模，估算工作量。第个过程主要是用例角色复 杂度和用例事务数的识别，角色可以是人，计算机或者组织,关键是分清它用什么方式 与系统交互，查到对应的权重,从而计算获得未平衡角色数；事物是指从用户到 系统 再到用户的一个 回路”根据场景描述确定每个用例的事物数，同样查询其对应的权 值之后计算得到未平衡用例数，最后这两个数值相加得到未调整功能点数。第步中复杂度 因子的计算主要分为技术复 杂度因子TCF和环境复杂度因子ECF两类，与功能点 估算中调整因子的计算方法相同，对各个项目分别 打分后得出两个复杂因子。第 步，软件规模UCP即为技术复杂度因子TCF

12、淋境复杂度因子ECF漱 件规模 UCP。最后根据历史数据确定每个 UCP完成的工作量（通常为16人时30人时,与 计算所得的UCP相乘即为开发工作量，在此之外,用例点模型将项目管理、质量保证 等时间作为补充效果SE计算,补充效果SE+开发工作量就是最终的估算结果。四.过程规划、预测与监控中的度量。这一章主要简单地说一下对项目评估预评审技术 （PERT、原始的CoCoMo模 型、诤值分析以及项 目监控中数据分析的理解。由于理解不是特别深刻 ，所以只能 简单的描述一下现有的了解。关于 PERT,我认为最主要的就是对三个数据的评估, 即乐观的0D （不考虑效率和中断，完成任务的最小时间量、 悲观的P

13、D （考虑各种培 训、生病以及工作时间做与工作无关的事情等各种延误情况和最有可能的ED （不是OD和PD的中间值，而是根据经验估算认为的最可能的情况。根据这三个值得出 项目的beta分布及其图像（使用beta分布而不是用正态分布的原因是人们的评估往往偏向于乐观，图中使得左右两侧 面积近似相等的分割线所对应的时间即为最可能 的工作量。这种估算方法需要策划小组人员分别进行估算得到结果后，再对结果按照一定的策略进行对比分析，得到最终的估计值。原始的CoCoMo模型是用于软件开发不同阶段的三个模型的集合。基本、中 间、详细这三个层次的 模型分别用于对项目了解很少、明确需求、完成设计以后 三个阶段，但都

14、具有相同的形式，即E=aSb F。E是按人月计算的工作量,S是按千行 交付的原指令数目的测量规模，F是调整因子（不同层次的模型中取 不同值，a和b 又根据软件的三种类别（有机式、半分离式和嵌入式分别取不同的数值。诤值分析法是为了将项目的范围偏差跟踪、进度偏差跟踪和成本偏差跟踪统一 起来。这个方法的核心 是比较准确的估算出工作完成的百分比。计划的费用PV是一条表示期望值的基线，代表着截止到某一时刻计划完成的工作，可以用计划消耗 的费用来表示；实际的费用AC表示截止到某一时刻实际的成本；诤值EV表示截止 某一时刻，实际完成的工作应该消耗的成本。同一时刻的 EV与PV的单一变量是工 作量,分别是实际的工作量和计划的工作量，所以这两个值可以得出进度的偏差；AC 与EV的单一变量是 实际的费用，分别是实际消耗的费用和计划消耗的费用，所以这 两个值可以得出成本的偏差。这是两个最 重要的偏差。五.产品设计质量度量与控制。我认为非功能性需求是软件度量中最容易被忽略的，也最不容易被清晰掌握的 部分。在需求分析中，常见的非功能性需求虽然都能设计感官需求、易使用性、安 全性、可