??
本文来源：谢老师的博客
当一个企业要进行过程改进的时候，首先要做的事情就是发现和定义问题，然后针对问题找出解决方案。问题很多，但判断问题需要有个基本的界限，那么这个界限是什么呢的企业说我们的文档不标准，也有的说我们的过程不标准，还有的说我们的做事风格不标准。是，这些都是问题，但根本的一条，企业进行软件开发的目的是提高经济效益。过程改进的目的不仅仅是写漂亮的文档，也不是仅仅关注文档的写法，而是要尽可能提高效率、降低成本、满足质量要求，一句话，我们是为着提高企业的经济效益才会下功夫进行过程改进的。
因此，当我们致力于发现和定义企业存在的问题，以期找到过程改进目标的时候，应该重在挖掘影响效率的因素，并且形成解决方案。近年来人们对此作了很多研究，一些积极面对风险、更大程度上对于规模经济的改进技术已经广泛为人们所接受。既然讨论软件经济学就离不开讨论工作量与成本模型，为此，我们需要对一些基本知识有一些了解。
1，统计数据的线性回归
成本模型最基本的构造方法是使用回归技术，这个研究也为我们构造自己的估计模型奠定了基础。通过对大量项目的统计，我们可以以此为基础建立一个基本模型（公式），然后估计就可以通过其他二级成本因子进行调整。
假定，我们已经对机构历史上大量以代码行为基础的规模度量S，和人月为基础的工作量E的数据进行了统计。直接画出散点图，可以看出由于点很散，关系很不明显。
但我们发现，把两个变量都取对数以后，有了明显线性的关系。也就是说，在两个轴都取对数以后，有了最小的残差。
根据这张图，我们可以写出回归直线的表达式：
log E = log a + b log S
把这个式子由对数域转换到实数域，就变成了指数关系式：
上式就是根据回归直线计算出的规模（以代码行记）与工作量（以人月记）之间的数学模型。我们可以推广出来作为后一步的估计公式使用。这个式子表明，规模和工作量之间，具有明显的指数率关系。这也与我们平时观察到的经验规律是吻合的。
2，CoCoMo模型
在20世纪70年代，Boehm开始研究从加利福尼亚TRW咨询公司的大量项目中收集的数据。并且研究使用这些数据规律。1981年Boehm根据多年研究，导出了构造性成本模型（COnatructive COst MOdel，CoCoMo）。Boehm是第一个从经济学的角度看待软件工程学的研究者。
原始的CoCoMo实际上是三个模型的集合，分为基本、中间、详细三个层次，分别用于软件开发的三个不同阶段。：
基本模型：当对项目了解很少的时候使用，用以估算整个系统的工作量(包括软件维护)和软件开发所需要的时间。
中间模型：明确需求以后使用，用于估算各个子系统的工作量和开发时间。
详细模型：当设计完成以后使用。用于估算独立的软部件，如子系统内部的各个模块。
这三个模型都是静态、单变量模型，具有相同的形式。
其中：E是按人月计算的工作量。
S是按千行交付的原指令数目（KDSI）的测量规模。
F是调整因子（在基本模型中为1）。
Boehm把软件划分为有机式（又称组织型）、半分离式（又称半独立型）和嵌入式三类，允许不同应用领域和复杂程度的软件按照三类软件的适用范围选取相应的参数。
组织式系统：包括数据处理，一般要使用数据库，集中在事务处理和数据恢复上，包括银行和账务系统等都是有机式系统。
嵌入式系统：包含一个集成在硬件的大系统中的实时软件，比如导弹制导系统、水压传感系统等。
半分离式系统：介于有机式和嵌入式之间的系统。
基本模型中三种类型的系统工作量的a和b的数值见下表。
通过选用开发方式和使用适当的工作量公式，CoCoMo可以生成一个工作量的初步估计。
中间CoCoMo模型可以使用基本模型参数，也可以使用经过调整的参数如下表：
在工作量估计公式中乘以工作量调节因子 EAF
工作量调节因子EAF与软件产品属性、过程属性、计算机属性、人员属性有关
四种属性共15个要素。
每个要素调节因子的值分为：很低、低、正常、高、很高、极高，共六级。
Boehm推荐的Fi值范围为：0.70, 0.85, 1.00, 1.15, 1.30, 1.65。
当15个Fi的值选定后，EAF的计算如下
EAF＝F1*F2*……*F15
调节因子集的定义和调节因子定值是由统计结果和经验决定的。不同的软件开发组织，在不同的历史时期，随着环境的变化，这些数据可能改变。
使用中间CoCoMo模型可以估算开发软件产品的工作量，比较各种开发方案的工作量。
3，CoCoMo 2.0
从CoCoMo基本模型开发后的许多年后，软件工程技术发生了很大的变化，迭代式生命周期过程已经实现，面向对象的开发已经成为主流。这样，CoCoMo模型对于这些新技术是不灵活和不准确的，为此，Bochm定义了CoCoMo的升级版，也就是CoCoMo 2.0。
CoCoMo 2.0估计过程是基于任何开发项目的三个主要阶段：
阶段一：项目通常通过构造原型来解决具有高风险的问题：包括用户界面、软件系统的交互、性能和技术成熟度。这里，由于对所考虑的最终产品可能规模了解很少，在开发周期的早期阶段获得代码行计数是不可能的。在CoCoMo 2.0中使用对象点来计算规模。其中包括服务器数据表的个数、客户机数据表的个数、以及重用以前项目的屏幕和报告的百分比。
阶段二：随着开发工作的进展制定相应决策，但是设计人员必须开发出可以二选一的架构和操作概念。这个阶段，还没有足够的信息来支持细粒度的工作量和持续时间的度量，但由于功能点估计在需求阶段已经获取了功能性，因此，他们提供了比对象点更丰富的系统描述。
阶段三：系统开发已经开始，我们已经知道了更多的信息，这个阶段符合原始的CoCoMo模型，程序规模可以用代码行来计数，很多成本因子也可以用适当的方式来估计。
除了规模，这三个阶段还存在其它的一些差异，下表对他进行了总结。
例如，CoCoMo 2.0合并了重用模型、考虑了维护和损坏、需求变更等等。成本驱动器与CoCoMo相似，但也有了一些新的内容，还有一些重新计算的值。
两种版本的CoCoMo模型对比如下表所示。
如果我们不是具体计算工作量，而是希望抽象出其中的规律，那么我们需要仔细分析CoCoMo模型的构造思想，我们可以发现CoCoMo 2.0中认为软件开发工作量和四个基本参数有关：
规模：产品需要人工编写的组件规模（代码行或者功能点），这里也包含了复杂度。
过程：开发产品所使用的过程，尤其是避免管理上的低效率。
团队：团队的工作能力，开发者对于领域问题与编程两方面的经验。
工具：团队所使用的开发工具自动化的程度。
这个模型是下列函数：
显然，工作量的指数性与“过程”的特点有关，这个模型给了我们改进经济效益很好的启示。我们可以从规模、过程、团队以及工具四个方面寻求提高经济效益的解决方案。
软件经济学有一个非常重要的观点，也就是工作量和成本之间表现出非规模经济的特点。规模经济的特点是成本随着规模的增加而减少，但在软件中是成本随着规模的增加而急剧上升。这种急剧上升还来自于处于幂次位置上的“过程”这个要素，这个数据通常大于1.0。可见，尽可能减少软件开发规模和复杂度，改善软件开发过程，是提高软件经济效益最有效的手段。
4，从多个层面进行改进
由于软件开发是一个系统，所以从经济学的角度来说，如果只是从一个方面来考虑软件经济性的改进，看不到各个要素相互间的影响，所得出的结论并不能指导组织提高软件的经济效益。换句话说，一个组织如果只关注一个方面的改进，也可能这种改进成果很大，但并不可能取得很大的经济效益。我们经常看到这样的情况，有些单位下了很大决心、调动各方面的资源进行过程改进，但是改进的结果成熟度是上去了，但是并没有真正提升经济效益，最后的结论往往是：高的成熟度等级唯一的好处，就是好拿项目。其实这个结论是很狭隘的，原因何在呢键就是这种改进仅仅关注的是过程这个局部，而不是用系统化的方法真正从过程改进中获得更大利益。
要在商业表现中获取实质上的改进，需要均衡的处理上述简化CoCoMo模型的四个基本参数，也就是：规模、过程、团队和工具。同时这也是我们关注经济表现改进的优先级顺序。我们需要关注下面几个层面的问题。
1）降低软件开发的规模或者复杂度
? 理解业务需求，仅交付对于满足需求必不少的那一部分，以此降低总体规模。
? 通过设计上合理分解，使子系统和模块相对独立，以这些独立单元为中心开发。
? 通过基于组件和复用技术来降低人工编写的代码量。
? 使用面向服务的架构提升抽象度。
? 减少一次发布的功能数，缩短发布周期，增量式的交付功能。
2）改进软件开发过程
? 把瀑布过程转为现代的迭代过程，减少废品和返工。
? 坚持优先关注架构的原则，早期解决重大风险。
? 发现和评估开发低效率的区域，改进这些区域的习惯。
支持过程薄弱区的改进。
3）建立更优秀的团队
? 提高个人技能。
? 改进团队交互。
? 发挥团队的主动性和创造力。
? 提高组织级能力。
需要注意，这些改进经济效益的方法具有综合的依赖关系。例如，以独立单元为中心开发可以使迭代过程得以实现，减低规模的方法也引起了过程的改变，过程改进推动了工具的进步，改进了人之间的交互更容易早期解决重大风险。
另一方面，改进软件经济效益还应该关注软件行业的一些重要趋势包括：敏捷的价值观和方法论；云计算和面向服务的架构；利益相关人与团队的紧密合作对于适应市场变化的影响等。
（待续）
来源：lujunql
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！
