当前位置:刘伯温高手心水论坛1 > 软件量度 >

度量软件研发成本即将有法可依 中国银行软件中心试点应用初尝甜

  企业或机构每年投入了大量的人力进行软件开发,它们该如何客观地量化研发的投入产出,提升软件研发成本管理?政府机构该如何为“金字工程”软件项目预算审批提供科学依据,如何为集中采购环节建立科学的软件项目成本评估体系?在软件项目交易中,甲方如何了解项目成本及供应商报价的合理性、提高商务谈判议价能力?乙方又该如何保障项目费用估算结果准确,依据行业标准的报价更能得到甲方的认可?一旦产生软件项目合同纠纷,软件项目成本评估的司法鉴定该以何为据?

  “因为缺乏统一的软件成本度量标准,业界普遍使用专家经验法来估算软件的工作量和成本。而专家经验法最大的问题是:无法复制、很难在不同组织之间取得认可,缺乏科学性和准确性等。”作为行业标准组织编写和试点应用的主要负责人,中国软件行业协会过程改进分会副秘书长代寒玲向记者介绍,已经制定完成即将发布的《软件研发成本度量规范》迎合了迫切的市场需求,有着强烈的现实意义。

  国务院某直属机构A是国务院的直属正部级机构,实行全国垂直管理,约有员工 5 万人,对信息化程度要求非常高,是国家某“金字工程”的牵头单位。以“金字”工程为主线的业务信息化系统开发、推广应用和运营管理主要由科技司负责,而A单位内部具有独立的信息化研发团队,团队规模约有 2000 多人。每年约有信息化项目 20~30 个,信息化投资约两三千万元。

  1.预算申报、审查主要依靠专家经验:预算申报主要依靠专家经验,导致估算偏差较大,偏差原因无法追溯,不同专家之间很难达成一致。预算审查往往以某些专家无奈妥协完成。

  2.基于代码行的估算存在弊端:信息化承建单位经常以代码行的方法进行项目预算,代码行在预算阶段难以估算且规模受开发方案及人员影响较大。

  3.研发管理自成体系:该单位内部的研发团队相对独立,对于行业主流情况了解相对较少,这 2000 人的研发水平、效率与国内水平相比究竟处于何位置,是信息化主管领导急需了解的,以便支撑改进决策。

  4.需求模糊为变更埋下隐患:在项目预算阶段,各业务部门提交的需求粗细程度不一,有些需求虽然写的篇幅很大,对功能描述的语言很多,但没有描述到关键点上,为后续项目开发工作埋下了严重隐患,直接导致需求变更加剧。

  国家某总局B为国务院的正部级直属机构。B单位集中采购中心负责起草该系统内的政府采购规章制度及规范性文件,管理、指导、协调和监督该系统的政府采购工作,其中也包括信息化软件项目采购。B单位目前运行着 20 多个业务软件和10 多个行政管理类软件,每年信息化投资上亿元。

  没有单独的软件研发团队,信息化项目的开发工作主要以委托软件厂商进行的B单位也面临着不少问题:

  1.商务谈判时,无据可依,全凭专家经验:信息化采购需统一按照政府采购流程进行,各项软件开发工作量评估和谈判工作,由谈判小组实施,而谈判文件中缺少明确的软件工作量评估的原则、方法及流程,以致谈判小组成员无据可依,全凭经验评估,导致谈判专家之间评估差别很大。

  2.无法识别合理性报价:在信息项目招评标中,由于该局系统较复杂,软件项目类型多种多样,包括新开发、升级完善、运行维护等类型的软件系统,各投标商报价方法五花八门,报价千差万别,以致招标方无法合理识别投标商报价,双方谈判口径不一致,谈判效率非常低下。

  3.系统延续性强,商务谈判地位弱势:由于该局大量项目是在既有系统上进行功能的修改、扩充及维护,因此延续性较强,不宜频繁更换供应商。此外,由于双方知识背景不对称,使得商务谈判议价时甲方所提疑问经常被乙方所谓的复杂技术所挡住,无法了解真实的生产成本。

  C公司是一家深圳证券交易所上市公司,是国家火炬计划重点高新技术软件企业,北京市双软认定企业,拥有员工 1000 多人,公司通过了 CMMI3 级评估,主要业务集中在为“金宏工程”、“金财工程”、 “金盾工程”、“金质工程”等多项国家重大信息化建设工程。

  2.面对新的业务领域,专家经验估算法偏差巨大,导致项目亏损。公司随着业务的不断拓展,经常涉及新的领域,由于专家经验的局限性,在进行新业务项目的估算时,估算偏差巨大,使得项目出现投入不足,工期延期以及项目亏损。

  某人民法院接到一个因甲乙方双方无法就软件项目工作量、成本达成共识,甲方拒绝支付乙方软件开发费用,最终乙方将甲方告上法院的案件。案件的关键点是如何评价该软件项目客观的工作量、成本,以便使被告、原告方达成一致。由于司法鉴定系统内无单位有能力提供相关鉴定,使得案件审理陷入僵局。

  在这起案件审理中,乙方(原告)根据软件行业比较常见的软件项目工作量、成本估算方法对该项目进行了估算,并向法院提交了估算结果。由于估算方法主观性较强,并且所用数据缺乏依据,甲方(被告)拒绝接受乙方的估算结果。而由于软件本身的特殊性,其开发工作量、成本影响的因素非常多,目前国内司法系统中缺乏对此类软件项目进行成本鉴定的权威方法,所以无法提供有效的依据来解决原告、被告的诉讼分歧。

  某国有大型银行是四大国有商业银行之一,信息化程度高。该银行的信息化建设以自主开发为主,拥有独立的研发团队,团队规模有数千人。该行软件中心是科技体系建设的重要组成部分,负责该行应用软件的统一管理、开发、技术支持等。

  1.如何量化研发部门的研发产出和价值: 随着该行组织级量化管理的不断提升,高层领导对信息化管理的量化提出了新的要求,金融信息化每年投入了大量的人力进行开发,那么多工作量投入,如何能客观地量化相应的产出?

  2.传统功能点(IFPUG)方法难以应用在项目早期:2008 年该行软件中心引入的 IFPUG 传统功能点,主要在项目需求规格说明书确定之后使用。随着中心管理流程的变化,需要在项目早期立项阶段就要进行功能点计数,而传统的功能点无法在项目早期进行可靠的计数。由于产品类型复杂、性质差距较大,用传统功能点既有因子统一估算,导致不同项目类型之间估算误差较大。

  3.已有的项目工作量估算方法主观性较强,缺乏相对客观、稳定的验证手段:已有估算模型建立的过程中,为了满足管理需要,对相关的调整因子依靠专家经验进行了调整和定义,于此同时又人为地引入了其他偏差因素,导致模型估算结果不稳定,带来其他管理难题。

  4.估算及评审人员能力尚待提高:内部的估算专家团队,由于项目背景经验不同,不同专家在对功能点及估算方法的具体理解有着一定的偏差。同时由于专家团队人员较多,能力水平层次不齐,每年实践估算机会较少,整体估算技能及实践水平尚待提高。

  国务院某组成部门D的信息化主要由科技司负责规划、统筹、建设、管理,而信息化建设主要由内部的研发中心负责,少量采用外包模式。该单位拥有独立的研发中心,研发团队约 500 人,每年约有几十个软件开发项目,研发中心已获得了 CMMI5 级资质。

  1.依赖专家经验,估算效率底、估算偏差大:软件项目预算申报、审核时,往常采用甲乙方专家一起,通过开集中评审会进行,往往耗时一个月时间,20多位专家参与,由于专家意见不统一,导致估算偏差大,会议效率低下。

  2.引入了传统功能点方法,对功能点的应用是“又爱又恨”:引入传统功能点方法,让甲乙方找到了共同“语言”,但在实际落地时却很难在项目早期应用。这是因为每年开发的项目类型复杂、性质差距较大,套用功能点估算时,甲乙方因视角不同,各自增加了非常多的主观因素,导致甲乙方之间估算结果差距较大、互不认可,各自都有各自的理由。

  上述几个案例分别从预算审批、招投标商务谈判、司法鉴定、内部管理等角度说明由于缺乏统一的软件成本度量标准所带来的问题。“实际上,在软件项目招评标过程中,由于无法界定软件工程项目的合理成本范围,常常出现恶意低价或超高价格竞标现象,甚至出现1元竞标、10元竞标的问题。这种现象既会让信息化项目的建设很难切实有效地执行,也会造成以价格为参考的恶性竞争,不利于软件行业的可持续发展。”代寒玲说。

  她说:“在工业和信息化部软件服务业司的领导下,2010年软件成本度量国家行业标准研制工作正式启动。我们分会和电子四所会同产、学、研、用约40多个单位组建了标准起草组,围绕软件研发成本度量标准体系建设开展了基础性研究工作,梳理了行业标准体系,并推动了相关行业标准立项。起草组对国际、国内软件成本度量标准化情况以及最新度量实践开展了全面调研,并结合企业的实际需求,确定了《软件研发成本度量规范》的关键技术路线年底形成标准征求意见稿。”据了解,该标准从2012年开始在海关总署、国家税务总局中国人民银行、中国银行、安利集团、神华信息、东软集团600718股吧)、中远资讯、中创软件等单位试点应用。

  “标准本身更多的是对软件成本构成进行定义、对度量过程、方法和原则进行规定和描述,即告诉大家度量软件项目成本的方法。对软件项目来说,最头疼的是人力成本的度量。标准给出的大致的技术思路是:先按照国际标准估算项目的功能规模,再根据行业基准数据或企业基准数据回归的数学模型和调整因子,得出项目的工作量,然后根据人月费率估算出项目的成本区间。” 代寒玲特别强调,标准建议给出的估算结果是一个合理的区间,而不是一个值。用户可根据自身情况,在合理区间内选择一个合理值。

  她还介绍:“我们已经初步建设了行业级的软件过程基准数据库,并会定期发布我国软件生产力基准数据。但因为国家标准化方面的相关规定,所有将来可能会变化的数值,都不能在标准中出现。所以,为了更好地指导用户参考行业基准数据来应用标准,我们还编制了配套的应用指南,相关行业基准数据和参数都收录在内。将来,软件质量竞争力公共服务平台建成后,也可通过该平台发布数据。”

  实际上,“成本度量行业标准”是中国软件行业协会过程改进分会正在牵头研究的“中国软件质量竞争力计划”(简称“Q计划”)中第一阶段的重点工作。

  中国软件行业协会过程改进分会执行秘书长王钧向记者介绍,所谓Q计划是从2012年到2020年的一个中长期规划,它承接国家2012年发布的《国家质量发展纲要》和2011年发布的“国发4号文件”。该计划还在征求意见中,将于近期发布。

  从成本度量标准本身来讲,代寒玲认为,其主要价值和意义主要有三点。第一是给出了一个科学、统一的方法,使大家使用统一的语言去交流和沟通。第二是倡导用户使用国际标准对项目规模进行估算,使得估算结果可以比对、持续改进。第三是使得估算过程更加透明,估算的结果可追溯。

  她介绍,《软件研发成本度量规范》试点单位的反映良好,规范解决了试点单位长期以来在软件项目规模、工作量、成本度量方面面临的问题。在试点期间,全国范围内共涌现出了大约400名CCEP(软件成本估算专家)。

  本文所述案例1中的国务院某直属机构A “2012 年新立项的 14 个项目,由于有独立第三方介入,以行业标准以及客户内部的历史项目基准数据为依据,形成的项目成本评估报告项目,其评估结果获得了双方的一致认可,顺利通过了预算审查会,成功立项,且预算节约了 8%。” 王钧说,“案例3中的C企业通过引用行业标准、行业基准数据,对项目进行第三方评估,以评估结果帮助甲方进行了预算申报。评估结果接近 4 家同行业同规模公司报价的平均值,偏差约正负 10%。”

  “案例4中的某法院出具的第三方评估报告,所采用的方法符合行业标准。它采用的调整因子来自于行业基准数据,出具报告的单位是拥有着权威第三方地位的行业协会,最终双方达成共识,法院依照评估报告的结果进行了宣判。” 王钧讲起规范软件研发成本度量标准带来的实际好处时滔滔不绝,“案例5中的某大型银行不仅引入并建立了适合早期立项阶段的快速功能点估算标准,弥补了传统功能点在项目早期估算不足的难题,完善了项目整个周期的估算,还通过对已有的功能点估算的方法、过程、数据进行梳理、分析,制定了优化方案,建立了适合项目不同阶段、不同产品线、不同应用场景的功能点方法应用指南,同时通过对项目经理、业务主管、过程改进人员、研发骨干等 144 人进行培训,并引入了严格的 CCEP认证考试,筛选并建立了 116 名符合行业标准的软件成本估算专家队伍,为软件成本估算方法落地奠定了人才基础。”

  中国银行是国内唯一一家连续经营超过百年的商业银行。软件中心是中国银行信息科技体系的重要组成部分,是总行的直属部门,人数近两千人,承担着全行海内外应用软件的研发和维护支持工作。同时也是实现中国银行总行科技引领战略部署,推进创新发展、转型发展、跨境发展的主要开发力量。

  中国银行软件中心主抓这项工作的总监姚丹介绍,软件中心一直重视软件过程体系建设,2009年成为首个通过CMMI4级评估的国内金融软件企业。“软件成本的控制关乎软件研发的质量、过程改进和资源配置。能不能建立一套科学合理的被大家接受的成本度量机制,以工具、数据、度量作为基础来进行管理,关系到企业的生存和发展。所以从这个层面来说进行成本度量分析自然是我们一项重要工作,这是我们引入行业标准的背景。”

  管理大师德鲁克指出:没有度量就没有控制,没有控制就没有管理。姚丹说:“目前,国内外仍然没有统一的软件规模度量方法。究其原因,是由软件研发工作的固有属性决定的。软件研发本质上是一种智力活动,其过程复杂、非结构化程度高,而人类对自身智力活动的认识还有待提高。软件研发的许多投入不能清晰地确定,而其产出物主要是无形的。正是软件研发的这些属性和特点给予其规模度量工作很大的灵活性,软件规模度量方法百花齐放便成为很自然的事。”

  姚丹介绍,早在2005年,中国银行软件中心就启动了相关方法的研究工作,并于2010年定制形成了软件中心内部的功能点估算方法、建立了配套的管理体系,2011年在全中心范围内推广使用。2012年他们启动了软件成本度量过程改进专题,一方面在内部进行研究改进,另一方面引进外部先进的理念和优化方法。

  “之前我们也采用按项目投入人天的度量方法来反映项目的投入量,而功能点方法,很好地解决了如何度量面向业务需求产出规模的问题。以投入产出的度量分析作为过程改进输入,来进一步提高管理的精细化水平。” 姚丹说。

  功能点度量是基于需求功能的软件规模度量方法,是度量生产效率的一个关键点。主要负责推进这项工作的中国银行软件中心主任工程师薛勇说:“这项工作由中心EPG组织牵头作为过程改进专题工作,下面有两个主要部门:一个是总体部,主要负责功能点规模估算;另一个是项目管理部,负责工时登记及生产效率,整体工作以跨部门工作组形式推进,工作组直接向我汇报。”

  他介绍:“大规模软件开发同样需要度量生产效率。如果只有工作量,缺了规模,效率就没法衡量。从工作量估算的角度,必须先估算规模,然后参考历史的生产率数据建立基线,最后得出工作量及周期。如果没有数据基础,就没有历史数据供参考,只能拍脑门了。”

  规模估算有多种方法,中国银行原来采用代码行估算规模,但是发现有局限性,这个规模产生于设计或编码结束后,作为事后度量还可以,但在项目早期阶段仅凭需求是不太容易估算出代码行的。所以要找到一个方法,能解决事前估算、事中监控、事后度量的问题。2007年,中国银行就开始接触功能点方法,但是当时更多地是根据书本上的理论,试图拿一把尺子量所有人,基于项目建立组织基线,最后发现挑战太大了,大家都在质疑估算结果的准确度,其原因有两个方面:

  第一,原始模型的变动因素,比如功能点里面的14个调节因子,看起来像是计算机处于七八十年代早期背景的非功能约束,其理论上最大值对于功能点规模有30%的影响。估算人员可以根据自己的解释,随时对这个刻度进行调整,这就失去了权威性。

  第二,当时建组织基线是基于项目的,但中国银行的组织架构形式、人员配备都是基于产品的,项目是动态的,产品团队才是静态的。比如今天是ABC三个产品组合产生的生产效率,明天是DEF产生的生产效率,他们之间没有可比性。另外利用这些数据进行度量管理也存在问题,假如该项目生产率出现了问题,如何知道是ABC中谁的问题呢?

  2010年中国银行重新引入了标准功能点的方法,这次重点解决了以上两个问题。首先,根据各个产品系统情况分别自定义14个调节因子系数并相对固化,因为中国银行的项目大部分都是在已有的产品上做增强型改造。只有当非功能特性如系统架构发生了重大调整才允许变动,但是变动的数值及变动的频率要严格控制,这样就把30%的波动减少了。其次,按照整体IT产品系统架构规范确定系统边界,按照产品系统分解功能点,按照产品及项目维度分别建立各自生产率基线,在估算时分别计算并累计总工作量,度量目前确定的方针是产品团队自己和自己比。

  “引入标准功能点方法后,我们也遇到了一些问题,如立项之前的快速估算问题。我们在立项之前会根据需求做概要功能分析,架构设计及概要产品设计形成技术方案,然后估算工作量及周期并计算项目成本供立项审批决策使用。但这个阶段时间比较短,不可能等所有需求分析完成才开始。需求分析是我们立项后的第一个实施阶段,标准功能点在需求分析后形成。另外,对标准功能点的理解和掌握是否准确,估算及评审人员的相应技术资质如何解决,已有估算数据是否准确都是问题。还有,即使是那14个标准的调整因子,我们都是坐在井里面自己琢磨的,同业怎么搞,行业标准、国家标准到底是什么,我们能不能和行业标准对标,这也是我们需要重点解决的。” 薛勇说。

  参与行业标准《软件研发成本度量规范》的试点应用,采用这个标准推荐的快速功能点方法,薛勇认为:“通过和协会的合作,我们请协会的专家对中心现行标准进行了评估和改进,对历史评估数据进行了抽样检查,找出存在的问题,补充了适用于立项前的快速功能点估算方法,基于以前标准功能点累计的数据对快速功能点估算的加权因子进行了测定,对人员进行了培训及CCEP技术认证,基本解决了我们遇到的问题。”

  “目前我们正在按照完善后的标准执行。快速功能点估算方法在规模估算上分别针对新建和增强型产品作了适当简化,通过基于标准功能点建立的生产率历史数据的套算关系,解决了立项前时间短、需求尚未详细分析情况下的快速估算问题。在立项后的需求分析阶段,我们仍然采用标准功能点进行估算规模,并以此作为度量的规模数据。每年我们会分析两者差异,套算简化系数及对应关系。”薛勇介绍,“在生产率度量方面,我们重点根据同一产品并行任务的稳定性及沿时间轴的变化趋势找出生产工艺及过程改进的问题,提升生产效率。这是我们在大规模软件开发模式上扩展管理半径,进行精细量化管理的基础。”

  “在协会专家及我中心共同努力下,通过现场调研诊断、方法优化及导入培训、历史数据审查分析等一系列活动,我们取得了适用于项目不同阶段的规模估算方法、中国银行软件中心工作量估算模型等一系列成果,同时有一百多名员工通过CCEP认证,为后续工作的开展奠定了良好的基础。2013年,这些成果将在中国银行软件中心内部全面推广应用,我们也将在此基础上,对应用情况进行跟踪、验证,持续优化调整,并逐步建立软件中心的基准数据库,强化中心的量化管理能力。同时,我们认识到,对于软件产品,除了功能方面的需求以外,还有相当比例的非功能需求。比如说金融软件产品在安全性、可靠性、易用性、运行效率、可维护性等方面都有较高要求,需要投入相当大的精力去解决,相应的研发工作量投入也会增加。对此方面,我们也将在标准应用中有目的地总结估算和应用经验,研究适用的度量方法,作为功能点方法的有益补充。”姚丹总结说。

http://juliekusyk.com/ruanjianliangdu/270.html
点击次数:??更新时间2019-06-16??【打印此页】??【关闭
  • Copyright © 2002-2017 DEDECMS. 织梦科技 版权所有  
  • 点击这里给我发消息
在线交流 
客服咨询
【我们的专业】
【效果的保证】
【百度百科】
【因为有我】
【所以精彩】