成本估算的软件标准简介
1、行业标准《软件研发成本度量规范》 本标准规定了软件研发成本度量方法、过程及原则,包括软件研发成本的构成、软件研发成本度量过程、软件研发成本度量的应用。
本标准适用于度量成本与功能规模密切相关的软件研发项目的成本。
本标准不涉及软件定价,但相关各方可依据本标准明确研发成本,从而为软件定价提供重要依据。
标准研制背景长期以来,如何度量和评估软件研发项目的成本一直是产业界的难题。
目前我国尚无科学统一的软件研发项目成本度量标准体系以指导、规范、管理软件项目的研发成本,较大程度导致做预算时无据可依,造成极大浪费;在软件项目招评标过程中,由于无法界定软件工程项目的合理成本范围,常常出现恶意低价或超高价格竞标现象;软件开发商在项目实施过程中,由于缺乏成本控制的科学依据,也经常出现时间滞后、费用远远超出最初估算水平的情况。
标准研制过程在国家工业和信息化部软件服务业司领导下,从2010年开始启动我国软件成本度量标准体系的研制工作。
中国软件行业协会系统与软件过程改进分会 (以下简称 “过程改进分会”)和中国电子技术标准化研究院(以下简称“电子四所”)围绕软件研发成本度量标准体系建设开展了基础性研究工作,梳理了标准体系。
核心标准《软件研发成本度量规范》于2010年12月正式立项,计划号为2010-3194T-SJ,由过程改进分会和电子四所共同牵头起草,组织产、学、研、 用约40家单位共同参与,历时3年,为软件项目预算、立项审批、招投标、项目计划、变更管理等工作提供“科学依据”。
标准的价值1、倡导使用统一的国际功能点方法度量软件规模,使度量结果可比对;2、倡导使用基准数据估算软件工期和成本,使估算结果更科学;3、倡导使用一致的估算过程和公式,使估算过程透明化、估算结果可追溯。
标准试点应用《软件研发成本度量规范》从2012年开始试点应用。
海关总署、中国人民银行、东软集团等单位都参与了试点工作,分别在预算审批、项目立项、招投标、项目计划等场景进行应用,取得了很好的效果。
截至2013年年底,共有约2000人参加CCEP培训,近1500人通过考试并成为国内首批CCEP(软件成本估算专家)。
采用标准规定的方法后,极大的解决了试点企业长期以来面临的问题。
标准发布行业标准《软件研发成本度量规范》(SJ/T11463-2013) 由中华人民共和国工业和信息化部于2013年10月17日正式发布,并于2013年12月1日开始正式实施。
最新进展经推荐,该标准由中关村智联软件服务业质量创新联盟 牵头,正在申请升级为国家标准,于2015年7月31日正式下达计划号:20151553-T-469 2、北京市地方标准《信息化项目软件开发费用测算规范》1、规范研制背景 北京作为全国软件与信息服务业之都,产业规模一直位居全国前列,并且保持着较快的增长水平,软件和信息服务业在全市经济发展中也占有越来越重要的地位。
随着十二五规划的逐步实施,北京市各行各业信息化建设投资也不断加大,仅全市每年属于市级财政拨款范畴的信息化项目就可达700至800个,金额总量可达三十多亿元,涉及上千家企事业单位。
然而本市一直没有科学统一的标准以支撑、规范、管理信息化项目软件开发费用的测算,这大大制约了北京软件产业的健康可持续发展。
由于相关标准的缺失,如何测算信息化项目软件开发的合理费用一直都是北京软件产业发展中的难点,因而常常导致软件项目预算审批无依据、恶意竞标等问题的发生。
2、规范的价值 由北京市经济和信息化委员会归口指导,北京软件和信息服务交易所、北京软件行业协会过程改进分会联合制订的北京市首个软件成本度量地方标准《信息化项目软件开发费用测算规范》于今年11月起正式实施,这标志着我市信息化项目软件开发工作拥有了科学、标准的费用评估方法,有助于规范行业市场、推动软件企业提升生产效率,提升产业增长质量。
3、联盟标准《行标应用指南(预算场景)》 1、编制背景 长期以来,如何度量软件研发成本一直是产业界的难题,尤其是在预算、招投标、项目计划等活动中因为缺失科学统一的软件研发成本度量标准,较大程度导致项目做预算时无据可依,进而造成预算浪费或预算不足;在软件项目招投标过程中,因为缺乏软件研发成本度量依据,恶意竞标、低价中标现象频频发生;开发方在项目实施过程中,由于缺乏成本控制的科学依据,也经常出现时间滞后,费用远远超出最初预算的情况。
科学统一的软件研发成本度量标准既是有效进行软件项目管理的重要依据,也是当前软件产业发展的迫切需要。
为此,工业与信息化部软件服务业司委托中国软件行业协会系统与软件过程改进分会牵头组织编制了《软件研发成本度量规范》。
标准中规定了软件研发成本度量的方法及过程,包括软件研发成本的构成、软件研发成本度量过程、软件研发成本度量的应用。
其目的是帮助软件研发涉及各方科学、一致地进行成本度量。
但标准中没有包含软件研发成本度量过程中所需要的估算模型、行业基准数据及其在不同场景进行成本估算的详细步骤和方法,因此需要制订标准的应...
软件研发成本度量规范的建立及应用 缪燕 在软件和信息服务的多少页
很多人不懂反抄袭软件是什么,反抄袭软件,又可说是反剽窃软件,主要是针对高校学生、老师论文撰写时的抄袭(不指正常引用)而无奈的情况下,开发的“学位论文学术不端行为检测系统”。
下面我们一起来了解一下什么是反抄袭软件。
什么是反抄袭软件?反抄袭软件有什么特点基本释义武汉大学信息管理学院硕士导师沈阳副教授,曾申请和获得等多项反剽窃专利授权,他说,20世纪90年代后,互联网的普及,包括搜索引擎、文献资源库、翻译软件的大量涌现,导致剽窃现象快速蔓延。
过去,论文剽窃多靠人工发现,实际上,编辑难以从互联网的海量信息中找到稿件的剽窃来源,也不可能熟悉相关稿件的细化研究领域,这使得剽窃作品被查出的风险较小。
2008年4月,沈阳副教授自主研发了“ROST反剽窃系统”软件,目前已在全国20多所高校院系推广和100多家期刊社使用。
2009年,华中科技大学、华中师范大学、武汉工程大学等高校的研究生院将启用“学位论文学术不端行为检测系统”,对研究生学位论文进行检测。
检测技术原理及说明目前,国内的反抄袭软件主要有两套:一套是由中国学术期刊电子杂志社与清华同方知网共同研制的学术不端行为检测系统;另一套是武汉大学副教授沈阳研发的ROST反剽窃系统软件。
这两套软件都只对高等院校和科研单位进行检测服务,而且免费,但并不对公众开放。
由中国学术期刊电子杂志社与同方知网公司联合研发的“反抄袭”软件,采用一套称为“学术不端行为检测系统”,这是世界首个用全文文献为比对资源检测抄袭行为的软件系统。
每一次检测,待检文章首先按照篇章、段落、句子等层级分层处理,然后创建指纹,而比对资源库中的比对文献,也采取同样技术创建指纹索引,根据其重合处的比例,判断该论文是否存在抄袭行为。
目前,这个系统用做比对的资源库,是有6000万条学术文献的数据库及上百亿网页的网络资源库。
特点反剽窃系统是通过比对源文档和目标文档的相似性给出相似度结果的一种信息处理系统。
由武汉大学信息管理学院出版科学系教师沈阳副教授研发的ROST 文档相似性检测工具可以有效检测论文的抄袭相似情况,经过六年的研发,终于推出了功能强劲的6.0版本,在定版过程中得到了武汉大学信息管理学院多位专家教授的宝贵意见。
目前ROST 反剽窃系统6.0版已经投入多家单位进行使用,反应良好,最大程度地杜绝了有抄袭可能的论文发表问世。
ROST反剽窃系统的技术特点:1.覆盖面广,通过混合引擎覆盖约188亿个网页和490万篇论文。
系统采用自研的ROST WebSpider算法实现了对互联网和期刊网的广度覆盖。
但需要提醒您的是,本反剽窃系统不能覆盖所有文献。
2.模糊检测,柔性匹配,不管抄袭者如何替换部分字符,删除部分标点符号,系统都能通过相似度来进行判定,让抄袭者无所遁形。
系统采用自研的ROST Similar算法实现高速相似性检测和度量。
系统采用自研的QingQing算法提取信息指纹,在P3、512MBPC上,分词速度为13MB/S,已在互联网提供评测版供业内评测。
3.引文及参考文献去除,使得误判的可能性降至最低。
4.分块检测机制,将文章的每一文本块与其他文档的相似度都精确的表示出来了,每一文本块约为200字至400字不等,以红色表示极度相似(相似度大于80%),一目了然,清晰醒目。
5.相似文档模块跟踪技术,可以通过简单操作直接定位相似文档模块位置,直观明了。
6.方便的结果分析功能,自动分析文档相似结果,给出评价意见。
7.支持多种文件格式的文档,包括PDF、DOC、PPT、XLS、TXT等文档。
(PDF文件需另行安装ROST文件格式识别引擎)8.可将分析结果进行存盘为专有数据文件,不用反复查找浪费时间。
9.应用范围广泛:可用于抄袭鉴定、科技查新、专利查新、引用查询、转载查询等多个领域,也可用于追查文献的流传图,绘制文献的传播发布路线。
可以为多类学术机构、文献机构以及个人服务。
抄袭抄袭:指窃取他人的作品当作自己的。
包括完全照抄他人作品和在一定程度上改变其形式或内容的行为。
是一种严重侵犯他人著作权的行为,同时也是在著作权审判实践中较难认定的行为。
在认定上,对于不同作品、不同行业的认定标准差异很大,而且一般对于很多抄袭相关概念的认定都存在争议,在判断上很难做到具体。
在软件设计时期设计模块独立性的一班度量准则是?
软件工程是一门研究如何用系统化、规范化、数量化等工程原则和方法去进行软件的开发和维护的学科。
软件工程包括两方面内容:软件开发技术和软件项目管理。
软件开发技术包括软件开发方法学、软件工具和软件工程环境。
软件项目管理包括软件度量、项目估算、进度控制、人员组织、配置管理、项目计划等。
软件工程是六十年代末为了解决软件危机而出现的一门学科,一般来讲它包含开发技术与管理技术。
而软件过程是随作软件工程的开展,特别是近年来系ISO900系列与CMM方法的实践而逐渐时髦的一个概念。
它基于质量是做出来的,而非检查出来的现代质量理论。
在规范化的软件生产中,离开了软件过程是不可思议的。
区别在于“工程”和“过程”的不同,软件工程是指将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程,即将工程化应用于软件过程。
工程着重应用,软件工程一定是软件过程的一个“产出”,一个个性化的实例!工程也是由过程组成的。
软件质量度量评价准则有多少条??分别是什么??谢谢!!
CMM是指“能力成熟度模型”,其英文全称为Capability Maturity Model for Software,英文缩写为SW-CMM,简称CMM。
它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。
CMM的核心是把软件开发视为一个过程,并根据这一原则对软件开发和维护进行过程监控和研究,以使其更加科学化、标准化、使企业能够更好地实现商业目标。
CMM是是一种用于评价软件承包能力并帮助其改善软件质量的方法,侧重于软件开发过程的管理及工程能力的提高与评估。
CMM分为五个等级:一级为初始级,二级为可重复级,三级为已定义级,四级为已管理级,五级为优化级。
CMM是由美国卡内基梅隆大学软件工程研究所1987年研制成功的,是目前国际上最流行最实用的软件生产过程标准和软件企业成熟度等级认证标准。
目前,我国已有软件企业通过了CMM标准认证 。
SW-CMM(Capability Maturity Model For Software 软件生产能力成熟度模型,以下简称"CMM"),是87年由美国卡内基梅隆大学软件工程研究所(CMU SEI)研究出的一种一种用于评价软件承包商能力并帮助改善软件质量的方法,其目的是帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力,从而能按时地、不超预算地开发出高质量的软件。
其所依据的想法是:只要集中精力持续努力去建立有效的软件工程过程的基础结构,不断进行管理的实践和过程的改进,就可以克服软件生产中的困难。
CMM它是目前国际上最流行、最实用的一种软件生产过程标准,已经得到了众多国家以及国际软件产业界的认可,成为当今企业从事规模软件生产不可缺少的一项内容。
CMM目前通用流行的版本是1.1(Version1.1)。
《按照软件工程研究所(SEI)的原来计划,CMM的改进版版本2.0(V2.0)是要在1997年的11月完成的。
但是,美国国防部办公室要求软件工程研究所(SEI)延迟发放公布CMM版本2.0,直至他们完成另一个更为紧迫的项目-CMMI。
CMMI(Capability Maturity Model Integration能力成熟度模型集成),是美国国防部的一个设想。
他们希望把所有现存的与将被发展出来的各种能力成熟度模型,集成到一个框架中去。
这个框架用于解决两个问题:第一,软件获取办法的改革;第二,从集成产品与过程发展的角度出发,建立一种包含健全的系统开发原则的过程改进。
CMM为软件企业的过程能力提供了一个阶梯式的改进框架,它基于过去所有软件工程过程改进的成果,吸取了以往软件工程的经验教训,提供了一个基于过程改进的框架;它指明了一个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序,一步一步的做好这些工作而使软件组织走向成熟。
一、CMM的诞生 信息时代,软件质量的重要性越来越为人们所认识。
软件是产品、是装备、是工具,其质量使得顾客满意,是产品市场开拓、事业得以发展的关键。
而软件工程领域在1992年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来的成就总和。
软件管理工程引起广泛注意源于20世纪70年代中期。
当时美国国防部曾立题专门研究软件项目做不好的原因,发现70%的项目是因为管理不善而引起,而并不是因为技术实力不够,进而得出一个结论,即管理是影响软件研发项目全局的因素,而技术只影响局部。
到了20世纪90年代中期,软件管理工程不善的问题仍然存在,大约只有10%的项目能够在预定的费用和进度下交付。
软件项目失败的主要原因有:需求定义不明确;缺乏一个好的软件开发过程;没有一个统一领导的产品研发小组;子合同管理不严格;没有经常注意改善软件过程;对软件构架很不重视;软件界面定义不善且缺乏合适的控制;软件升级暴露了硬件的缺点;关心创新而不关心费用和风险;军用标准太少且不够完善等等。
在关系到软件项目成功与否的众多因素中,软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。
由此可见,软件管理工程的意义至关重要。
软件管理工程和其它工程管理相比有其特殊性。
首先,软件是知识产品,进度和质量都难以度量,生产效率也难以保证。
其次,软件系统复杂程度也是超乎想象的。
因为软件复杂和难以度量,软件管理工程的发展还很不成熟。
软件管理工程的发展,在经历了从70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化生产时代,到90年代中期,以CMM模型的成熟模型和日益为市场接受为标志,已经进入以过程成熟模型CMM、个体软件过程PSP和群组软件过程TSP为标志的以过程为中心的时代,而软件发展第三个时代,及软件工业化生产时代,从90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础,已经渐露端倪,估计到2005年,可以实现真正的软件工业化生产,这个趋势应该引起软件企业界和有关部门的高度重视,及早采取措施,跟上世界软件发展的脚步。
软件生产转向以改善软件过程为中心,是世界各国软件产业或迟或早都要走的道路。
软件过程改善是当前软件管...
我想问在SPSS里面什么时候度量标准用“名义”,什么时候用“序号...
展开全部 1、“序号”一般是用来定义等级差别的,例如对某个餐厅满意度,就可以用序号来表示,1、2和3分别代表满意,一般和不满意。
2、“名义”一般是用来代表某物的一个属性,没有任何比较排序的意义,只是说这个物有这个属性而已,例如人有男女之分,还有你说的“工号”也只代表工人的一个属性而已。
3、“度量”则表示可以不仅可以进行排序而且还能对结果进行加减的一种属性,例如“职工收入”,“体重”等等。
SPSS中常用专有名词解释: 1、变量视图:变量视图用于管理变量的属性,包括变量名称,类型,标签,缺失值,度量标准等属性。
2、数据视图:数据视图用于管理录入的数据,一行表示一条记录在不同变量下的值,一列表示相同的变量在不同记录中的值。
3、变量类型:SPSS主要包括 3 种类型,分别是:数值型,字符型和日期型, 度量标准:在SPSS 中,按照对事物描述的精确程度,可以将变量分为 3 种度量标准,度量(Scale),名义(Nominal),序号(Ordinal),因为不同的变量度量标准适用不同的统计模型,因此正确定义一个变量的度量标准很重要。
4、度量(Scale)变量:通常也称为连续变量,表示变量的值通常是连续的,无界限的,如员工收入,企业销售额等。
“度量”则表示可以不仅可以进行排序而且还能对结果进行加减的一种属性,例如“职工收入”,“体重”等等。
5、名义(Nominal)变量:通常也称为无序分类变量,表示变量的值是离散的,相对有限个数的,通常变量值的个数不超过 10 个,但值之间没有顺序关系的,如性别。
“名义”一般是用来代表某物的一个属性,没有任何比较排序的意义,只是说这个物有这个属性而已,例如人有男女之分,还有你说的“工号”也只代表工人的一个属性而已。
6、序号(Ordinal)变量:通常也称为有序分类变量,表示变量的值是离散的,相对有限个数的,但值之间是有顺序关系的,如教育水平取值有:1 — 8 年,2 — 10 年,3 — 15 年,这些值之间存在顺序大小关系。
“序号”一般是用来定义等级差别的,例如对某个餐厅满意度,就可以用序号来表示,1、2和3分别代表满意,一般和不满意。
参考资料 CDA数据分析网:http://cda.pinggu.org/view/21301.html...
软件复杂度的复杂度的种类
有模块、类和程序三类复杂度。
模块复杂度包含了关于模块的复杂度信息;类复杂度是针对那些使用McCabe面向对象特性的程序,它包含了关于类的复杂度信息;程序复杂度包含了关于程序的复杂度信息。
集成复杂度报告对应于三种复杂度的是三种复杂度报告。
如果一个报告的复杂度信息不只一种,那么就把这些复杂度信息组合成新的报告。
集成复杂度信息只收集一个部件及其下级的信息。
例如:如果一个程序级报告包含一个类复杂度,那么只报告组成程序的类的信息,而不包含类组成的信息。
McCabe复杂度是对软件结构进行严格的算术分析得来的,实质上是对程序拓扑结构复杂性的度量,明确指出了任务复杂部分。
McCabe复杂度包括:圈复杂度、基本复杂度、模块设计复杂度、设计复杂度、集成复杂度、行数、规范化复杂度、全局数据复杂度、局部数据复杂度、病态数据复杂度。
McCabe复杂度的用途在软件工程中,有三种使用McCabe复杂性度量的方式。
作为测试的辅助工具。
McCabe复杂性度量的结果等于通过一个子程序的路径数,因而需要设计同样多的测试案例以覆盖所有的路径。
如果测试案例数小于复杂性数,则有三种情况一是需要更多的测试;二是某些判断点可以去掉;三是某些判断点可用插入式代码替换。
作为程序设计和管理指南。
在软件开发中,需要一种简单的方式指出可能出问题的子程序。
保持子程序简单的通用方法是设置一个长度限制,例如50行或2页,但这实际上是在缺乏测试简明性的有效方法时无可奈何的替代方法。
不少人认为McCabe度量就是这样一种简明性度量。
但是要注意,McCabe度量数大的程序,不见得结构化就不好。
例如,Case语句是良结构的,但可能有很大的McCabe度量数(依赖于语句中的分支数),这可能是由于问题和解决方案所固有的复杂性所决定的。
使用者应当自己决定如何使用McCabe度量所提供的信息。
作为网络复杂性度量的一种方法。
Hall和Preiser提出了一种组合网络复杂性度量,用于度量可能由多个程序员组按模块化原理建立的大型软件系统的复杂性。
他们提出的组合度量公式为式中 C1,...,Ck是各个模块的复杂性;CN是网络复杂性;W1和W2为权值。
McCabe复杂度即可用于度量各个模块的复杂性,也可用于度量网络复杂性。
圈复杂度是用来衡量一个模块判定结构的复杂程度,数量上表现为独立路径的条数,即合理的预防错误所需测试的最少路径条数,圈复杂度大说明程序代码可能质量低且难于测试和维护,经验表明,程序的可能错误和高的圈复杂度有着很大关系。
独立路径组成的集合称为基本路径集合,独立路径数就是指基本路径集合中路径的数量。
基本路径集合不是唯一的,独立路径数也就不唯一。
因此,圈复杂度是最大独立路径数。
计算方法节点是程序中代码的最小单元,边代表节点间的程序流。
如果一个模块流程图有e条边n个节点,它的圈复杂度V(G)=e-n+2,典型的V(G)max=10。
图1中示例的圈复杂度是2。
优点避免软件中的错误倾向;指出极复杂模块,这样的模块也许可以进一步细化;度量测试计划,确定测试重点;在开发过程中通过限制程序逻辑,指导测试过程;指出将要测试的区域;帮助测试人员确定测试和维护对象;与所用的高级程序设计语言类型无关。
应用圈复杂度指出为了确保软件质量应该检测的最少基本路径的数目。
在实际中,测试每一条路经是不现实的,测试难度随着路径的增加而增加。
但测试基本路径对衡量代码复杂度的合理性是很必要的。
McCabe & Associates建议圈复杂度到10,因为高的圈复杂度使测试变得更加复杂而且增大了软件错误产生的概率。
提示:圈复杂度度量是测量在一个软件模块中的分支数目,在所有的开发周期中都要使用。
圈复杂度度量以软件的结构流程图为基础。
控制流程图描述了软件模块的逻辑结构。
一个模块在典型的语言中是一个函数或子程序,有一个入口和一个出口,也可以通过调用/返回机制设计模块。
软件模块的每个执行路径,都有与从模块的控制流程图中的入口到出口的节点相符合的路径。
“Cyclomatic”来源于非直接连接基本测试周期的数目,更重要的是,也通过直接相连的图表给出独立路径的数目。
通过图表的相关性,一个节点可到达另一个节点。
圈复杂度度量也可作为模块基本流程图路径的数目,其重点在于模块线形组合后,所产生的路径数目是最小的。
对圈复杂度的限制现在有许多好方法可以用来限制圈复杂度。
过于复杂的模块容易出错,难于理解、测试、更正,所以应当在软件开发的各个阶段有意识地限制复杂度,许多开发者已经成功地实现把对软件复杂度的限制作为软件项目的一部分,尽管在确切的数目上略微有些争议。
最初支持的数目是10,现在支持数目可达15。
但是,只应当在条件较好的情况下使数目大于10,例如开发者非常有经验,设计合乎正式标准,使用现代化的程序语言、结构程序、代码预排和先进的测试计划。
换句话说,开发团队可以选择超过10的限制数目,但是必须根据经验进行一些取舍,把精力花在比较复杂的模块上。
基本复杂度是用来衡量程序非结构化程度的,非结构成分降低了程序的质...