功能点

Function Point

联系我们 |   Contact Us

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

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

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

2015-1-4  点击率:9370
     20141225日下午与26日下午,北京随济科技首席顾问曹济老师接受某软件中心的邀请,作了题为“引入软件功能点,走出CMMI边缘化窘境”的现场报告,该报告在该软件中心激起了强烈反响。因为该报告与CMMI密切相关,而国内软件行业关心CMMI的人数众多,现将根据现场录音整理的节选内容分三次发布,以供那些运行CMMI管理模型和的软件组织作参考之用。下面为第三部分内容。

欢迎各位回来。刚才休息讲的统计控制方法弄得大家有点糊涂,这也正常,因为毕竟大部分同事只需要了解相应的结果而对于所采取的具体方法无需过多关注。其实刚才介绍的参数估计、假设检验都是一些经典统计学的内容,有兴趣的同事可以自己找些相应的参考材料来了解一下。好吧,接下来就是大家的时间啦,大家有什么问题可以提出来,我尽力回答。

问题1曹老师好!您谈到的这些专题都很有意义,其关键是要引入软件功能点方法,是吗?我们之前也曾经尝试过在项目中应用软件功能点方法,可是因为度量结果的差异过大,并且相互谁也说服不了谁,代码行虽说也有缺点还是能数出来,怎么样能保证不同人员度量出来的软件功能点结果一样呢?谢谢!

回答1:多谢您的问题,因为您的问题也是其他许多同事关心的问题。那就是怎样保证软件功能点度量结果一致性的问题。我们为不同企业辅导过软件功能点方法,往往会有两个极端的情形,一种认为软件功能点方法很简单,另一种则认为很难操作。第一种是想当然,他干脆不去数,所以认为很简单;您能提出这个问题来,说明您确实数过了,对吧?应该是。拿一个最简单的例子来说明,大家认为用户登录功能是什么类型的功能,外部输入、外部输出还是外部查询?好,有同事举手,您认为是外部输入,是吗?为什么?我转述这位同事的理由,他认为应该是输入类型,因为你登陆时输入了用户名和密码信息,不就是输入功能吗?怎么样,有没有不同意见?哦,这边的同时认为是外部查询,说说您的理由。刚才这位同事认为是外部查询,理由是登录时就是在后台查询相应的用户名和密码信息,所以是外部查询类型。你看,问题就出来,两个人两个答案,这样数功能点肯定不行,答案只能有一个,那是什么呢?一般来说是外部查询,二般的情形是外部输出。为什么?因为软件功能点度量是一个基于严格规则约束的度量活动,很多同事在不了解这一前提之下就去度量软件功能点,结果自然五花八门。正常的情形登录功能是外部查询功能,因为系统提供该功能的主要目的是向系统边界之外的用户呈现信息,登录功能符合这一主要目的,因而它是外部查询或者外部输出;一般而言,登录功能就是登录功能,它不会包含其他的行为,例如维护ILF、更改系统行为、计算或者生成衍生数据,所以一般的登录功能就是外部查询类型;而有些应用系统的登录功能在用户登录时是要记日志信息的,此时它就应该被判断为外部输出功能,为什么?因为它同时维护了ILF(用户登录日志ILF),这就是二般的情形。问题解决了吧?

所以功能点度量结果不一致,说明我们没有根据功能点规则去度量软件功能点,您想啊,假如软件功能点连这个基本问题都解决不了的话,那个维护功能点标准的IFPUG委员会这三十年都干什么了?顺便说一句,我也是IFPUG委员会的成员,当然,我们都是Volunteer(志愿者)。回答您的问题,一句话,严格遵循软件功能点规则,结果想不一致还困难了呢!

问题2您好!我是做中间应用平台开发的,主要为不同的外围应用提供各种服务,针对我们的应用也能使用软件功能点方法吗?如果要应用软件功能点方法,是不是只有我们开发组内部的人员才能数出来?

回答2:(略)

问题3曹老师,您好!我之前听过您的公开课,也读过您的《软件项目功能点度量方法与应用》一书,包括您最近出版的《IT项目量化管理》我现在正在看。您能给我们介绍一下其他软件组织,尤其是和我们相似的这种软件研发中心,包括产品研发项目、客户定制项目以及各种小规模的软件升级维护项目,他们应用软件功能点的一些做法吗

回答3:(略)

问题4曹老师好!我是产品定义组的刘伟,我们的工作内容是根据业务的要求对现有的功能进行配置,我们不做编码,但通过配置交付的功能也需要经过后续一系列的测试等活动,对我们这样的工作内容可以采用功能点方法来衡量吗?

回答4:您好!您提的问题很好,引出了我计划外的话题,我替大家谢谢您!软件功能点方法一般主要应用与典型的软件开发活动,您说的工作虽然也需要有很强技术背景的同事去完成,但功能点方法被这一类型的任务画在它自己的范围之外,不建议采用软件功能点方法。为了解决软件配置、代码数据、静态页面开发、数据库优化等许多非功能性的软件任务的规模度量,IFPUG标准最近推出了非功能规模的度量方法SNAP,使用SNAP方法可以度量出您所提到的数据配置的工作规模,从而推算出相应的软件功能点,我们已经做过一些非功能点度量的尝试工作,结果还不错,但缺点是软件行业可以借鉴的历史数据并不多。

问题5曹老师好!我还想继续前面的问题,您能大概给我们介绍一下你们公司实施软件功能点方法所需的时间范围、费用情形吗?包括实施软件功能点方法有哪些需要特别注意的事项?

回答5:(略)

问题6我们在实施CMMI过程中也收集了一些项目的数据,从数据分析的角度考虑收集多少项目数据比较合适?如何考虑软件项目中的加班情形?另外,您支持软件开发过程中采用加班方式吗?

回答6:您好!数据分析是一个比较大的话题,需要充分结合软件组织特点和组织的管理目标要求,否则很容易流于形式。关于项目数量多少的问题容易回答,多多益善。但是最少需要多少数据则没有明确的限定,有两个项目的数据就可以比较,对吧?但也得看这两个项目可比不可比,您拿一个中间应用的软件项目和BI项目去比对,它们的生产率可能相差四倍,这又有多大的意义?所以数据分析首先需要分类,然后每类数据再进行比较。根据统计学的计算结果,对于每类项目的数据量如何能达到30个最好,因为此时可以假定其服从正态分布,如果数据量不足,则需要引用t分布,相应的计算结果则比较发散。我的经验是对每类项目的数据量至少为8个以上,否则分析结果没有明显的统计意义。总结一下,每类数据至少8个样本, 30个样本更好,当然,样本的数量多多益善。

我们来谈谈加班的问题,这是一个与所有人密切相关的话题。软件行业的加班是家常便饭,不但中国使然,全世界的软件行业都存在大量加班的情形,区别在于国内软件行业的免费加班比例更高。如果从宏观经济的角度分析,免费加班是一国经济综合竞争武器中的“大杀器”,您瞧瞧欧洲那些资本主义国家,为什么寅吃卯粮、入不敷出啊?可不就是因为好吃懒做嘛。让我这么一说,大家觉得我是不是特支持免费加班啊?那可就彻底误会我了,加班偶尔为之也是正常的事情,如果持续性的大量加班则会使得人们产生抵触情绪。所以,我先回答您的最后一个问题,我支持偶尔为之的加班,例如平均每周的加班时间不超过两个半小时。我接触过一个客户,他们在一些重点项目组规定正常的工作时间为周一至周六,每天早九点至晚九点,有些同事在这样的项目中已经持续工作了两年的时间!遇到这样的情形我们无话可说,只能对该组织的领导表示由衷的敬意。

回头我说说如何从数据分析的角度来考虑加班工作量如何处理。虽然许多软件组织对于加班情形装作视而不见,但遵循实事求是的态度,还是应该在收集工作量时明确区分出哪些是正常工时,哪些是加班工时。让人失望的是,根据我们的分析结果,加班确实对软件的开发效率有明显的提升。所以数据分析的重点在于反映客观事实,最终的决策,例如是否加班,加班的程度如何则需要管理者综合各方面的信息进行决策。

问题7曹老师好!我们在部门内部现在也在尝试敏捷开发模式,您建议的功能点分析方法和数据分析方法有可能和敏捷管理方法结合吗?

回答7:(略)

问题8老师好!您前面谈到了SPC方法在软件项目中存在不适用的情形,据我所知,SPC方法也是六西格玛管理模式的一种主要方法,六西格玛管理模式不能应用到软件项目的数据分析中吗?

回答8:(略)

问题9曹老师好,比如我们要引入软件功能点方法,什么样的人员可以数功能点?需要他们具备什么样的基础?他们的工作职责只能是数功能点吗?还可以从事别的工作吗?

回答9:哦,这是一个没有标准答案的问题,我尽量给您一个满意的答复。一般来说,参与数功能点的人员最好要有一定的软件开发基础,另外因为软件功能点分析主要基于业务视角分析软件需求,所以也需要相关的行业背景。如果对于工作时间不长的同事,例如三年以下,参加的项目数量有限,因而不大可能建立完整的行业背景知识,所以在识别功能点时可能会面临一定的困难。不过凡事没有绝对,有三年以上的开发经验只是一个建议的标准,人员如果在责任心和主动性方面表现突出,也可以弥补软件开发经验方面的不足。

需要说明的是,软件开发经验的充足与否只是影响掌握软件功能点规则的快慢而已,软件开发背景较弱的同事可能需要花费更长的时间才能掌握软件功能点规则。大体而言,能够独立、完整应用软件功能点规则的一个参考标准是数出5000功能点。以正常的软件功能点度量速度衡量,学习阶段度量功能点的速度大概为每天能数出100功能点到200功能点;熟练之后速度可以提升到200功能点到300功能点。当然,具体功能点度量的速度还与需求文档的详细程度以及完备程度密切相关,上面只是我自己辅导客户时的经验数据。

数功能点和任何工作一样,要求人员具备强烈的责任心和主动性,另外,软件功能点的度量人员还需要较强的沟通能力,因为免不了和项目经理或者软件需求分析人员打交道,经常需要从他们的嘴里“撬出”文档外的实际软件功能。此外,软件功能点度量工作还需要人员具备细心和耐心,需要经常比对文档差异、在文档的不同部分寻找逻辑线索、在数据库文件中查找字段、查阅接口文档,个别情形下甚至去阅读历史项目的代码文件,而这些工作均需要细心和耐心。在我的印象中,度量软件功能点的人员的男女比例大概为1:3,要知道,在许多软件组织中男女比例为3:1甚至4:1

度量软件功能点是一个比较消耗时间的工作,但这不等于说软件功能点评估人员就不能从事别的职责。一般来说,软件功能点评估人员至少会将一半以上的经历投入到具体的软件功能点度量工作中,除此之外,他们还可以兼任项目管理、质量管理、需求分析、测试管理和测试执行等方面的工作,其实这些工作与软件功能点评估工作都有密切的关系。如果人员具备软件功能点评估能力,同时承担部分上述的工作职责,那他的工作就会如虎添翼,一定会取得不俗的成绩,因为他拥有软件功能点这个制胜法宝!

……

2015年元旦将至,祝各位领导和同事在新的一年里身体健康!工作顺利!工作万一不顺利,不要忘了寻求软件功能点的帮助哦!谢谢各位!