本文阐述了软件规模度量的基本策略，包括确定度量目的、范围、功能用户及需求描述的详细程度等内容，强调了度量策略的重要性。
很多公司在度量规模的时候，不重视度量策略阶段的活动，但是在后续的度量过程中往往就会遇到疑问，在遇到问题时，才发现原来没有做到度量策略的定义，没有确定好度量的前提，因此度量策略阶段虽然可能很简单，很快速，很例行公事，但是不能忽视。
1）确定度量目的：为什么执行本次度量。
软件规模度量的常见目的有：
作为估算项目的工作量输入；
作为计算缺陷密度的输入；
作为计算生产率的输入；
作为计算软件复用率的输入；
作为给客户报价的依据；
度量软件规模的变更；
作为估算后期维护工作量的输入；
……
目的不同，范围不同，度量出来的规模不同，度量的时机不同，对度量结果的精度要求不同。
图一 度量目的的作用
2）确定度量范围：究竟是度量哪些软件的规模。
在确定度量范围时，首先要把软件与其周围的硬件区分开来，尤其是对嵌入式系统的度量；
软件是划分层次的，通常情况下软件是分为：
应用层
中间件层
数据库层
操作系统层
驱动层
随着当今的软件开发技术的发展，应用软件与嵌入式软件的层次结构已经很类似了，和上边列出的5层基本一致。
对于具体的某个层次，还可以根据度量目的继续分层，比如把应用层继续分解为如下的3层：
界面层
逻辑层
数据层
如果采用SOA的方式开发软件，逻辑层还可以再细分下去。只要对度量目的有意义，都可以继续分解。
一般而言，不同层次的软件采用的技术方法、开发语言是不同的，所以其开发效率也是不同的，在度量时，不同层次软件的规模是否可以累加要根据度量目的来确定。宏观的度量范围可能跨层次，但是具体到某个功能，在度量规模时，是不能跨层的。比如我们在度量office中word软件的规模时，不会把操作系统的规模也加进来，我们只会在应用层度量其规模。如果我们是开发驱动软件的，我们只是度量驱动层的软件规模。
在COSMIC中定义了软件环境模型作为划分度量范围的一个理论基础。
3）确定功能用户：是给谁用的功能或站在哪些用户的角度度量软件的规模。
功能用户就是与被度量软件打交道的人、设备或软件系统。被度量的软件提供功能，提供服务给功能用户。功能用户不同，使用到的软件功能不同，因此度量的范围、度量出来的规模也不同。确定功能用户也是为了更精确的确定度量范围。
度量目的不同，识别的功能用户可能不同。
图二 划分软件范围的步骤
4）确定需求描述的详细程度。
我们来看需求描述的不同详细程度：
层次一：我们需要开发一套进销存管理软件。
层次二：在进销存管理系统，需要包含采购订单管理功能、到货入库管理功能、出库管理功能、销售订单管理功能、供应商基本信息管理、客户基本信息管理、商品基本信息管理等功能。
层次三：在采购订单管理功能中，能够新增订单、修改已有订单、删除订单、查询已有的订单。
层次四：采购订单管理功能的新增订单功能的用例描述为：
Actor | System |
进入新增订单功能 | 显示出订单格式 |
输入订单号、供应商 | 检查供应商是否是合法供应商，如果是，则可以录入，否则错误提示 |
输入采购日期，业务员 | 检查业务员是否存在，如果录入业务员不存在，则错误提示。 |
输入采购的多条商品，数量，单价 | 检查商品是否存在，如果录入的商品不存在，则错误提示。 自动计算进货金额。 自动计算本次采购的总金额。 |
点击存盘 | 保存采购单 |
上述的四种层次中，最详细的层次四是可以采用COSMIC标准方法进行准确度量功能规模的，这种层次在COSMIC中称为功能处理的颗粒度层级，即可以识别出来功能需求中的功能处理与子处理。所谓的颗粒度层级就是指需求描述的详细程度。功能处理的颗粒度层次在COSMIC方法有定义，通俗的理解与掌握就是可以编写出测试用例的详细程度，即需求达到可测试的程度。所谓的可测试就是指能够识别所有的输入信息，输出信息，输入到输出信息的转化方法。
需求描述的粗略则采用快速的、近似的方法度量规模，需求描述的详细则采用标准的方法进行度量。COSMIC方法支持项目早期的快速度量与需求明确以后的准确度量。对于快速、近似的度量软件规模，COSMIC有专门的指南来解释如何进行早期估算、近似估算。
扫一扫
4799
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
