第二周作业-软件工作量的估计

影响软件工作量的评估因素

　　对于软件工作量的评估，会牵涉到的因素有很多。根据我的了解，有使用的方法或者工具、开发者的熟悉程度、以及(部门之间的)利益关系、对项目的理解评估人员的个性。基于各种因素考量最后出现的工作量评估会有比较大的区别。

1.使用的方法（工具）

　　对于一个项目，如果甲是在现有的模块上去完成，而乙则是重新开始。那么他们对于这个项目工作量的评估也就自然不同了。现在假设一个项目由已搭建的前台和后台两个部分组成，甲方会认为他们需要处理的就是后台部分，工作量就是后台所需的时间，但是乙方可能会认为他们的工作量是前台和后台两部分的和，这样才是对整个项目的完成。

2.开发者的熟悉程度

　　这个容易理解，如果是一般对语言或是技术掌握不熟悉的人，花费的时间和返工的时间、沟通的时间自然就要长一点。

3.(部门之间的)利益关系

　　公司之间的外包项目，服务方就倾向于时间长一点，考虑的因素是假设用户需求会有一部分变化或者希望从中多賺钱。公司的部门之间也是类似，营销部门总是希望越快越好，但是开发部门总是认为营销部门没有更早提出需求等等。

4.对项目的理解或者评估人员的个性

　　同样一个项目，类似微信，如果1000个用户数和1千万的用户数，做法上会有非常大的区别。

软件工作量的评估方法

　　在此，分析几种常用的工作量评估方法：

　　一、通过功能点对软件规模进行评估。此种方法是实际工作中常常突出的法宝，有着大量的追随者，但由于其原始定义比较抽象，实际工作量与功能点之间的函数关系并不明显，常常还受制于技术选择。比如说，对于统计当前使用系统的用户数这一要求来说，采用B/S方式就很直接，而传统的C/S似乎就得费些功夫，两者的工作量明显不同。又比如，C/S中弹出一个模态窗体是很简单的事，但对于B/S好像也得多想想。

　　二、常用的评估方法还有类比法和专家法。由于历史数据的不丰富，类比法和专家法也很难奏效，更何况很多的企业也缺少使用这种评估方法的经验和数据。

　　如何测量软件规模这个问题自软件工程诞生起就一直是这个领域的焦点问题。软件产品或项目的功能规模是涉及软件开发和交易的成本、项目资源投入的预测、项目维护成本的预算、项目质量管理的要求以及产品上市的时间等方面的关键指标。因此，进行软件产品的功能规模测量显得尤其重要。目前，国内外软件领域的专家对软件功能规模测量开展了极富成效的研究，提出了各类工业标准。

国际标准化组织ISO/IEC相继发表了4个功能规模测量方法的标准，它们是：

——ISO/IEC 19761（COSMIC-FFP方法）；
——ISO/IEC 20926（IFPUG方法）；
——ISO/IEC 20968（MkⅡ方法）；
——ISO/IEC 24750（NESMA方法）。

　　其中，COSMIC-FFP方法声明可以应用于管理信息系统（MIS）和实时类型二类软件，如，家电中的控制系统、飞机售票系统等等，但是该方法不适合于复杂算法的系统与处理连续变量的系统，如：专家系统、模拟系统、自学习系统、天气预报系统、声音和图象处理系统等。IFPUG方法声明可用于所有类型的软件，MkⅡ方法声明可用于逻辑事务能被确定的任何软件类型，NESMA方法非常类似于IFPUG方法也可以用于所有软件类型。就我了解的稍微多点的COSMIC-FFP方法，该方法的过程主要有两个阶段，第一个阶段是映射阶段，映射阶段的目的是将软件的功能需求分解为功能处理、数据组、数据属性；第二个阶段是度量阶段，度量阶段的目的是将功能处理分解为数据移动，计算功能规模。