加载中…
个人资料
北京软件造价评估技术创新联
北京软件造价评估技术
创新联
  • 博客等级:
  • 博客积分:0
  • 博客访问:12,464
  • 关注人气:13
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

基于场景的软件早期估算

(2018-10-15 15:26:05)
标签:

软件规模估算

软件成本度量

软件造价

功能点

方法

美国著名的IT咨询公司——Standish集团,从1996年开始,在每年的报告中都发布关于项目成功率的统计信息,在这超过20年的时间内,虽然IT技术以及软件工程方法日新月异,但IT项目的成功率一直徘徊在40%左右。

为什么IT这么难以成功呢?

我们首先要先定义一下:项目“成功”的标准是什么?

国际上比较普遍的认识——按时,按预算,交付客户满意的结果。这里插一句,自从进入了21世纪,项目管理的理论一直都在强调着客户满意。

blob.png

仔细分析,这三个特点都与项目的“估算”工作有密切的关系。为了确保项目的成功,我们首先应该精确地进行进度、成本以及客户期望的估算。

对于软件项目而言,无论是什么估算,其基础都应该是“规模”的估算。也就是要对项目的内容进行“量化”的预估。

在众多的规模估算的方法中,“功能点方法”既符合ISO标准,也符合我国工信部的标准,应该是一个很好的工具。但是在现实中,无论是美国,还是中国,应用还不是很广泛。

挑战 

2017年,会迎来IFPUG(国际功能点用户组)章程发布30周年的纪念日。尽管已经走过了30年,目前,国际上的专家认为功能点方法正处于“上升突破期”。

blob.png

在功能点的发明地——美国,还是有很多软件企业不知道,或者是拒绝使用这套方法。我有一位朋友在美国,在世界第二大ERP公司工作过了十多年,他所在的那个团队还是在使用传统的“代码行”方法进行度量。

在中国的情况也差不多,功能点方法的应用主要还是集中在金融、电信行业中的有先进意识的大中型企业。

IFPUG组织的委员David Herron先生,也在2017年最新一期的发刊词中感慨:我们是先进的“少数派”。

之所以面临这样的“少数派困境”,主要原因就是:1、功能点方法需要投入较多的人力和时间成本;2、需要较高水平的功能点分析专家。

而使用“故事点”和“代码行”,需要投入的时间、人力成本就低了很多。

但是,也许信息的成本越低,意味着其自身的价值也不高。

这两种方法都没有形成国际标准,又各自有天生的缺陷。代码行法体现的是成本而非价值,容易造假;故事点法没有办法在不同团队之间进行客观的比较。   

那么,我们这些“少数派”如何去突破这个“上升期”,如何去撬动这个标准,而又不投入过多的成本?

应对挑战 

国际上有些组织在尝试“基于场景”的方法(behind the scenes),来解决这个问题,尤其是用来解决业内公认的难题——项目早期估算。

前几年,国内“万众创业”的时代,经常有土豪找到我咨询——做一个APP需要多少钱?这个问题真是很难回答。

所谓的早期阶段,项目可能还没有真正立项,仅仅是一个概念,一个想法。在这个阶段,项目的决策层最渴望信息——需要投入的人力、物力是多少?进度计划是多少?

而这个阶段,得到这些信息的基础往往又很薄弱——只知道软件的大概功能范围;根本达不到需求规格说明(specification)的层级。 

在这种情况下,如何快速的进行估算呢?

这里就可以用到所谓的“基于场景”法——

1、先找到组织或者项目最典型的场景;

2、对其进行功能点计数,建立起功能点字典(功能点样例);

3、将场景与用户的业务需求产品,例如:用例(use case)或用户故事(use story)建立折算关系,得到之间的“换算因子”;

4、在新项目的早期,梳理得出大概的业务需求产品后,就能快速计算出软件规模。

举个例子吧——某线下的教育公司X,准备进行“互联网+”,自己没有开发人员,需要找到合适的外包团队。因此在软件开发项目的初期,在招标之前,迫切希望知道大致的成本预算。

他们经过分析得出,其所需软件产品最典型的应用场景就是“课程注册”、“线上支付”、“在线学习”等等。

然后,找到功能点专家针对这些“场景”建立功能点字典——使用标准的功能点方法进行计数,得到相应个功能点数(FP)。再统计得出,对应此“场景”的用例数(use case),用户故事数(use story)。

这里说明一下,X公司中将“用户故事”定义为“用例”的组成部分、一种细分结构。

经过计算,可以得到下表的转换因子。

blob.png

有了这个数据基础,X公司可以针对新项目进行早期的规模估算——

方案一:

先梳理出新项目的场景数量;用数量乘上相应的转换因子,以得到粗略的软件规模结果。

例1:总计10个场景,软件规模即为1246.7个功能点(FP)。

方案二:

分析出所有场景的“用例”数量,用数量乘上相应的转换因子,以得到比较精确的软件规模结果。

例2:分析得出90个用例,软件规模即为1310.4个FP。

以规模结果为基础,再去网上查到2016年软件开发“生产率”的行业数据,就可以得出此项目的工作量。例1的情况,1246.7*7.16=8926人时;大概是50.72个人月。

再以北京地区的人月费率(2.43万/人月)为例,此新项目的预算即为123.24万元。

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有