功能点

Function Point

联系我们 |   Contact Us

北京随济科技有限公司
地址:北京石景山区实兴大街30号中关村科技园3号楼8层8055 邮政编码:100041
联系电话:010-87611052
E-mail:info@suiji.com.cn
功能点交流QQ群:222582410

当前位置:首页>功能点>功能点

引入软件功能点度量,走出CMMI边缘化窘境(1)

2015-1-4  点击率:9649
    2014年12月25日下午与26日下午,北京随济科技首席顾问曹济老师接受某软件中心的邀请,作了题为“引入软件功能点,走出CMMI边缘化窘境”的现场报告,该报告在该软件中心激起了强烈反响。因为该报告与CMMI密切相关,而国内软件行业关心CMMI的人数众多,现将根据现场录音整理的节选内容分三次发布,以供那些运行CMMI管理模型和的软件组织作参考之用。下面为第一部分内容。
 
(领导致辞以及开场介绍略)
……,根据SEI官方网站的数据,我国通过CMMI各级评估的软件组织数量保守估计也会超过一千家之多。实施CMMI 的效果如何则众说纷纭,我做了一些简单归纳,大概可以分为三个类别,分别是官方总结、软件开发人员总结和CMMI咨询服务公司的总结。官方总结多以各地政府、软件园区发布的各种简报形式出现,内容不外乎是多少家通过了CMMI相应的级别,当地的软件企业已经同欧美发达国家的软件开发水平看齐,如果有企业通过了CMMI5评估,一般不会忘了加一句,强调该软件公司已经达到了时间顶尖水平。软件开发人员的总结多以私下交流或者网上发帖等非正式、非官方的面目出现,论调几乎完全相反,一般性的评价为无效果,对目前的软件开发没有什么影响。有些极端的评价则认为是软件企业的CMMI评估就是为了拿到CMMI的评估证书,有强烈的弄虚作假嫌疑。还有一类是CMMI领域的咨询公司,咨询公司在官方场合与官方总结的论调保持一致,在私下里的交流呢,则倾向于软件开发人员的看法,但并不是完全赞同。咨询公司的基本态度是CMMI是个好东西,就是因为软件组织的领导和软件开发人员没有按照咨询公司的要求去实施,您看看现在弄成什么样子,真实让人痛心疾首啊。大家对CMMI的看法呢?你们已经是CMMI level 4了,应该有比较多的体会。噢,我看到后面的那个同事了,您请说。
 
“曹老师好!我们项目组参加了CMMI的评估,我是项目负责人。我觉得如果遵循CMMI的要求可以使我们项目规范化管理的程度明显提高,这也有利于降低项目所面临的各种不确定性,总体上我们项目组还是比较认可CMMI的”。
“我们感谢这位同事的输入,他一定是个模范项目经理,很少有项目经理愿意公开为CMMI站台。我能问一句,你们这个项目的客户是谁?”
“我们是一个产品研发项目,我们项目的客户是我们的产品规划部。”
“你们的产品规划部应该也是CMMI评估所覆盖的范围吧。”
“是”
“多谢您的回答,我们的问答先告一段落。看来我低估了我们软件开发人员对于CMMI发自内心的热情,不过这是一个不太正常的现象,我看到大部分的项目经理厌恶来自外部的各种管理约束。套用CMMI的术语,这位项目经理是一位好得不正常的项目经理,希望都能以他作为学习榜样”。
 
回到我们前面讨论的对于CMMI实施效果的三类评价,我自己倾向哪一类评价呢,我在2000年至2006年从事过CMMI实施和咨询工作,截止到2005年我与大多数CMMI咨询顾问的看法并无二致。但后来就发生了变化,因为你想啊,如果个别几家实施CMM或者CMMI的软件组织见不到什么效果,那可能是组织自身的问题,但如果大量实施CMMI的软件组织没有什么切实的效果说明什么问题呢?这边的这位同事说对了,那可能是CMMI本身就存在一定的问题。我当年这么怀疑也把自己吓了一跳:那可是美国国防部委托研究的模型,有那么多了不起的专家学者参与的研究工作,可能会有问题吗?另一个重要的原因是那时还年轻,自信程度不够,习主席不是说要“道路自信”嘛,那时候也没有别的道可参考啊,看到最初的CMM模型已经够让人大开眼界了,顶礼膜拜还来不及呢,哪儿敢轻易指摘它呢。现在不同了,因为脸皮与年龄俱增,下面我就说一说我对CMMI的一点感想,班门弄斧,各位多指正。
 
……任何自然学科和社会学科的发展都不可能一蹴而就,都在“与时俱进”,都在不断完善自身的过程之中。我想CMMI也不例外,所以我们不应该抱残守缺,也需要对CMMI进行适当的反思。反思的结果还是模型本身,不能说这些实施CMMI的人都不合格吧?怎么样在目前状况下取得实效这才是我们应该关注的重点,而不是横加指责,推诿责任,又是客户不讲理,外部环境多恶劣;又是开发人员层次低,不能理解过程改进的重要性;前10年就在抱怨的问题,现在仍然在抱怨,说明什么?说明CMMI本身没长进。
 
……,给大家介绍几位素未谋面的老朋友吧。按照出场顺序,他们分别是Allan Albrecht、Watts Humphrey和Capers Jones。对我们而言,三位老先生有两个共同特点,都是美国人;都在IBM有漫长的工作经历。大家可能自然会联想到另外三位顶尖的质量管理大师,戴明、朱兰和克劳士比。看来三人成众,屡试不爽啊。先说Allan吧,他和我们关系密切的举动就是提出了软件功能点模型,他与1979年前后提出了软件功能点模型的雏形,之后的软件功能点模型则由一个民间组织IFPUG进行持续维护至今。北京随济科技公司先后在2009年和2010年翻译了软件功能点标准CPM4.3.1和CPM4.2的两个版本,大家有兴趣可以了解一下。Allan提出了软件功能点模型之后,IBM就不断地在IBM内部推广应用软件功能点方法估算软件成本,目前全球认证的功能点专家CFPS人数IBM一家就占了大约四分之一的比例,大约300多人吧。但全球范围内应用软件功能点的组织并不十分普及,所以Allan的名声自然也就不及Watts Humphrey。对于Watts Humphrey,大家应该不会感到陌生,它是CMM/CMMI模型的创始人和奠基人。Humphrey先生的突出贡献在于以精细化的方式建立了完整的软件过程管理模型,这一尝试如此成功,以至于在软件相关的各个领域都出现了CMM类似的成熟度模型。
 
从外行的角度分析,Allan所做的工作无法与Watts Humphrey的工作并无直接联系,但对于了解CMMI体系的同事就可以迅速地建立二者之间的对应关系,即软件功能点方法是CMMI模型中的“度量分析”中所要求的规模估算模型的一种方法,软件功能点方法对于CMMI的庞大体系而言,似乎只是个无足轻重的小角色。关键时刻,软件功能点的旗手Capers Jones先生登场了。幸运的是,目前Capers仍然健在,他1961年就从佛罗里达大学毕业了,现在怎么着也有七十六七了吧,不过他看起来仍然精力充沛,满面红光。Capers Jones信奉的管理哲学与Watts Humphrey大相径庭,Capers认为,只要将软件开发的相关事实以客观的方式呈现出来,人们自己会采取有效的改进措施。这与CMMI所采取的居高临下的态度相映成趣,CMMI要求软件组织的实践必须符合CMMI模型设定的过程,而非基于结果关注。Capers Jones在近四十年的时间内就软件功能点方法积累了大量的实践经验,而这些经验则完全可用于充实CMMI度量分析过程域中的天然不足,即数据不客观和数据不可信的问题。所以我们撇开他们的分歧,重点关注软件功能点可能在哪些方面可以对CMMI进行支撑。通过我们自己咨询项目的实践,软件功能点方法可以充分让CMMI管理体系重新赢得开发人员和管理人员的信任,避免CMMI体系被边缘化的窘境。
 
欢迎各位回来,我们继续。下面我们举例介绍软件功能点方法的一些场景。其实软件功能点方法不止可以支持CMMI管理模型,它的应用更为广泛,各位要有兴趣的话,可以翻一翻我和温丽编写的《软件项目功能点度量方法与应用》一书,书中对于软件功能点的应用有更完整的介绍。
 
专题一:应用软件功能点改造软件成本估算方法
对所有的软件组织而言,成本估算或工作量估算都是个大问题。目前采用较多的方法包括代码行方法、模块法等比较主观的方法,这种主要基于专家主观意见的方法所获得估算结果的准确性通常达不到预期的要求;专家主观估算的最大问题在于对其他人不透明,只有从事过相关工作的人才能判断估算结果的可信与否,那些没有相似工作经验的业务人员和管理人员则无从判断。这就导致了很大的麻烦,软件开发成本或软件维护成本甲方无从独立判断,只能依赖于乙方的数据。
 
我就遇到过这样的情形,有一家股份制银行的CIO新上任,要求严格控制软件开发成本。原来给外包商开发人员的费用标准为22000元/人月,现在下调为20000元/人月,这样一来费用可以节约10%。“道高一尺,魔高一丈”,开发商原来针对某项目估算的工作量为50人月,现在改为60人月,大家自己想一想,这个CIO控制软件开发成本的愿望能不能实现啊?问题在哪儿呢?目前的软件工作量和成本估算的过程不透明,尤其对于非技术背景的业务人员和管理人员不透明。
 
如果引入软件功能点方法,问题就变得简单了。假如原来的费率标准为2000元/功能点,现在调整为1800元/功能点,可以控制成本吗?当然可以。因为如果大家都根据软件功能点来衡量项目的规模,不管是张三还是李四,数出来的结果都一样,接下来只要协商每功能点的单位成本即可。大家可以看一下这组示例,这是某个软件组织的历史项目数据,我们看到项目的样本数为130个,其中又进行了分类,这样就可以看到每一类型项目的单单位功能点对应用的成本变动情形。像上面那个CIO的举措我是不太赞成的,一般来说,每单位功能点的成本趋势是一个增加的趋势,您非要往下减,这不是完完全全的拍脑门吗?有同事说,我用代码行也是这样啊,先得到代码行数量,然后再设定每代码行单价。问题在于,不同人员估算相同的项目,得到的代码行能一致吗?更不用说代码行还要解决一大堆的问题,例如自动生成代码、混合语言编程、程序效率高低等都会使得代码行方法令人望而生疑。
 
到目前为止,那些采用了软件功能点方法的组织最大的收获即是软件成本估算的过程透明化和结果客观化。这也与我们国家目前倡导的“预算透明化”趋势不谋而合。