软件功能点估算
为了能更好地理解和掌握软件功能点估算的一些规则，本文通过介绍一个需求实例来展开软件功能点估算的介绍，欢迎各位专家批评指正。
新增需求：实现一个订单的录入，更新，删除、查询、打印、导出功能，其中用户界面如下。订单明细包含了订购的具体产品及数量的情况，明细记录数原则不限。导出、打印、更新、删除订单记录应先从图2的查询界面查出记录，再鼠标双击某记录进入图1的增、删、改界面，也可以选择修改或删除菜单后输入订单号进入图1的增、删、改界面，新增时订单编号自动产生，更新时订单编号不能修改。订单的明细记录在增、删、改界面可进行删除或添加处理，要添加时通过鼠标定位在编辑区按右键选择添加功能，然有会弹出一个产品列表来供操作者选择，材料代码和材料名称及单价是通过选择后自动添加的，不能人工修改，操作者只能修改订单数量，要删除时也通过鼠标定位在编辑区的某产品上按右键选择删除功能即可。打印版面通过打印模板定制并打印到打印机、导出版面也通过excel模板定制并输出到excel文件。其他说明：
1、用户表和产品数据表本次不变，订单功能开发仅仅是引用这些数据。
2、暂不考虑其它特殊业务逻辑和权限，如：不写日志、功能按钮不根据权限加以屏蔽。
功能界面情况如下：
图1：增、删、改界面
图2：查询界面
功能点分析：
1、首先我们来确定本功能涉及到哪些用户数据（ILF,EIF）因为新增需求是订单管理，故订单信息属于一个，另外在需求中提到用户表和产品数据表本次不变，订单功能开发仅仅是引用这些数据，所以用户信息和产品信息也是系统的ILF 或EIF，只不过本次新增需求时不计算它的ILF或EIF功能点，因为它没有改变，相信引用它的方式与以前一样，但在EI、EO、EQ中引用需要考虑其FTR复杂度。另外，需求又要求打印和导出需要使用版面模板，故应该有三个模本文件。订单类型没有提及需要动态从系统内部获取，根据一般经验应该是一个在程序中做死的下拉选择列表，到此这个新增需求涉及的ILF,EIF应为如下内容：用户数据列表
文件描述
类型
DET
RET
功能点数
备注
订单信息
ILF查询结果导出excel模板
ILF通过其他编辑程序修改，本系统仅引用订单导出excel模板
ILF通过其他编辑程序修改，本系统仅引用
订单打印模板
ILF通过其他编辑程序修改，本系统仅引用产品信息
ILF本新增功能不计算其功能点
客户信息
ILF本新增功能不计算其功能点
功能点估算案例 下面以员工管理系统为例，详细说明如何利用功能点估算法计算业务复杂度。 在员工管理系统中添加一个员工的资料，会使用到员工的一般信息、教育情况、工作经历和家属信息。员工隶属于某个部门，在本系统中会有一个对部门进行维护的功能。员工的工资则由另外一个财务系统提供。因此，其用例图如下所示： 图1 员工管理系统用例图 假设员工基本信息如下所示： ?员工ID（标签） ?员工名称 ?性别 ?生日 ?婚否 ?所属部门ID ?所属部门名称 ?受教育的时间 ?学校名称 ?所学专业
?工作时间 ?工作单位 ?工作部门 ?工作职务 ?家属的姓名 ?之间关系 ?家属年龄 ?工作单位 假设部门信息如下所示： ?部门ID ?部门名称 假设工资表信息如下所示： ?员工ID ?员工姓名 ?金额 ?单位 ILF和EIF的功能点数 本案例识别出来ILF和EIF功能点个数如下表所示。 EI、EQ和EO的功能点数 本范例识别出来EI、EQ和EO功能点个数如下表所示。
本系统的通用系统特性及其影响程度如下表所示。
最终调整后的功能点数量为： （19 + 25 + 9 + 5）* 0.84 = 48.72个 总结 功能点估算法是一个非常有用的对软件规模进行估算的国际通用技术，是项目管理人员必须掌握的工具。为了便于大家对功能点的技术进行理解和记忆，这里对其进行总结：由于计算机软件就是为了实现无纸办公，那么在估算功能点时应该多以用户的纸质表单为依据，每个表单就是一个ILF或EIF，表单上显示的字段都是DET，一个表单上的“核心”内容不管是由几个数据表来分别存放数据的，每个表都是一个RET。 简单来讲，ILF和EIF可以被看作数据库中的数据表，但是主、从表将被视为一个ILF或EIF。那么，ILF和EIF的复杂度就是由数据表中的字段DET和一个ILF或EIF自身所包含的主、从表个数RET来决定。在计算DET时主、外键只能算作一个。 EI就是对应用户增加、修改、删除的操作，EO和EQ都是用于用户查询的操作。EO和EQ 的区别是，EO查询时使用了数学公式或计算方法。EI、EQ和EO的复杂度是由FTR和DET 决定的。FTR的个数由ILF和EIF的个数决定，可以由主表中主、外键的个数来计算。在计算EI的DET时，只有用户在界面上直接输入的信息才算作DET，通过页面自动计算或转换的数据不能算作EI的DET。在EO和EQ计算DET时，报表的标题、页码等信息不能被计算为一个DET。
选用了FP功能点分析作为项目主要的估算方法．因为FP方法中有大量项目经验数据可以从网络上获得，同时其数据功能TLF、EIF，以及事务功能EI、EO、EQ的计算对经验数据依赖不强，只需对概念理解正确一般就可以正确估算了．在估算成本的时候，因为公司以前的生产率数据是以LOC为单位的，我利用软件工程书籍中的“逆火”经验数据，将 LOC转换为功能点单位，当然，这里必然导致一些误差。为了降低估算误差，最后使用Delphi专家分析法对估算结果进行了调整． 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下： ?功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法，则误差会比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 具体步骤包括： 1. 识别功能点的类型。 2. 识别待估算应用程序的边界和范围。 3. 计算数据类型功能点所提供的未调整的功能点数量。 4. 计算人机交互功能所提供的未调整的功能点数量。 5. 确定调整因子。 6. 计算调整后的功能点数量。
软件项目的估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的可重复性、估算工具的缺乏以及一些人为错误，都会导致软件项目的估算往往和实际情况相差甚远。据有关机构调查发现，约有60％的软件项目的失败是因为估算偏差引起的，而不是因为技术实力不够。因此，估算偏差已被列为软件项目失败的四大原因之一。 从软件工程学上，我们知道软件需求和估算是软件项目的基础。因为只有准确的了解客户的需求，以之为基础，并使用科学的方法对目标软件系统的规模、工作量和进度做出合理的估算，我们才能在预算内按时按质顺利的完成项目。然而，软件估算作为软件项目的基础领域却常常被人们所忽视。我在近期的一个开发项目中就尝到忽视软件规模估算带来的苦果，结果是项目进行到一半时就发现不但工期严重滞后于计划，而且项目的各种资源也严重的不足和缺乏，项目被迫暂停下马。 常见的项目规模估算失准原因 一直以来，软件项目的规模估算（Size Estimation）是个争论不休的问题。不论是对软件开发团队还是对软件用户，软件规模估算的重要性都是不容置疑的。因为它能极大的影响着甲方对发包软件的成本估算，乙方对自身开发成本的预测，以及乙方对开发过程的量化管理等诸多方面。而且，只有相对合理和相对准确地估算软件规模，才能对项目的进度安排、资源分配等各个环节进行合理的部署。所以，软件项目的规模估算是软件项目中相当重要的一环。但是，以下的原因却使到我在这次项目的实际操作中对项目规模估算失准了： （1）对项目规模估算认识不足 项目规模估算一般分为两种应用场景：一是招投标的时候用来估价、报价；二是用来安排进度计划和指导项目具体工作的分配。因此，如果对规模估算认识不足的话，将可能会在这两种应用场景中估算失准。例如，如果项目规模低估的话就会造成人力估算低估、成本预算低估、日程过短，最终人力资源耗尽，成本超出预算。最后为了完成项目不得不赶工，不但会影响到项目质量，甚至会导致项目失败。而如果规模高估的话，就会因估价过高而降低了招投标时的竞争力，或在进度安排时提高了开发成本和浪费资源。由于对规模估算的认识不足，使到我在这次项目中就尝到一个大苦果，就是低估项目规模导致项目需要多次的追加预算。我不但多次受到公司领导的批评，而且还受到客户的多次投诉。 （2）个人经验估算法带有一定的局限性 一般来说，依靠历史或个人经验的规模估算方法都有一定的局限性。原因是很难在项目分析和计划阶段就对软件的规模进行相对准确的估算。因为估算是依靠评估人员的经验，所以对评估人员的能力要求比较强，并且难以由第三方对评估人员的工作偏差作出修正。在这次项目的初期，我片面的只是根据个人经验进行估算，结果是轻率的估算了项目规模。这是最后导致项目失利的原因之一。另外，不同软件项目使用的技术不一样，这一点也非常影响到软件规模的估算。例如同一个功能,使用JAVA语言和使用Ruby语言所涉及的代码行相差数十行，
功能点估算法介绍及 应用
一、功能点估算法识别项目范围和数据复杂度 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下： ?功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法，则误差会比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示，首先大家应该了解功能点估算法的使用步骤。 图1 功能点估算法的步骤 具体步骤包括： 1. 识别功能点的类型。 2. 识别待估算应用程序的边界和范围。 3. 计算数据类型功能点所提供的未调整的功能点数量。
软件项目中的功能点法估算-原理 FunctionPointEStimation功能点估算是一种用来估算项目大小的技术。 功能点是对软件功能和规模的间接定量测量，它基于客观的外部应用接口和主观的内部应用复杂度以及总体的性能特征。 功能点法和专家法估算的不同点在于对估算规模的细化的定量分析上面．我们在用专家法估算的时候往往会直接去估算工作量，或在规模的估算中掺杂了生产率的数据，导致估算数据出现问题．专家法估算虽然有时候也很准确，但不能提升为组织级可以参考和借鉴的同样规则．其实专家法的估算要做准确也是遵循了功能点法估算的思路，在考虑一个软件功能究竟涉及到哪些操作，涉及到多少数据文件的存在，每个操作需要访问哪些数据文件等相关问题．只是这些想法停留在专家头脑里面而没有量化出来． 我们的预测，分析和决策能力要提升，就必须对我们的经验进行模型化和定量分析．功能点法正好就起到了这个作用．其实功能点发也有不完善的地方，这可以根据我们项目实际的使用情况去不断的改进． 功能点发进行估算的时候具体过程是： 1.对估算功能单元的类型进行识别 2.计算每种类型的复杂度． 3.计算总体的调整前的功能点数 4.根据调整因子对功能点数进行调整 功能点估算中有5种信息域需要进行描述：其中事务类的有EI,EO和EQ，数据存储类有ILF和EIF.
外部输入(EI):通过界面等的输入，插入更新等操作都是典型外部输入 外部输出(EO):仅仅输出，入导出，报表，打印等输出 外部查询(EQ):先要输入数据，在根据输入数据计算输出，如查询 内部逻辑文件(ILF):可以理解为业务对象，可能对应多个数据表 外部接口文件(EIF):其它应用提供的接口数据 A.对事务类功能点的估算： 对事务类的功能点估算需要确定DET和FTR两个指标： DET:可以理解为界面的录入具体数据项，按钮也要作为数据项 FTR:事务功能需要操作的数据文件的数目 对EI的复杂度的计算： 对EO和EQ复杂度的计算： B.对数据存储类功能点的估算 对数据存储类功能点的估算需要确定DET和RET两个指标 DET:具体数据存储文件的数据项的数目 RET:数据文件是复合文件时候关联或引用的个数．如订单数据文件由于存在订单头和明细关联引用,RET应该算2. 对ILF和EIF复杂度的计算： 信息域数据估算完成后可以开始考虑调整因子：
功能点估算法识别项目范围和数据复杂度 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下： ?功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法，则误差会比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示，首先大家应该了解功能点估算法的使用步骤。
软件功能点估算 为了能更好地理解和掌握软件功能点估算的一些规则，本文通过介绍一个需求实例来展开软件功能点估算的介绍，欢迎各位专家批评指正。 新增需求：实现一个订单的录入，更新，删除、查询、打印、导出功能，其中用户界面如下。订单明细包含了订购的具体产品及数量的情况，明细记录数原则不限。导出、打印、更新、删除订单记录应先从图2的查询界面查出记录，再鼠标双击某记录进入图1的增、删、改界面，也可以选择修改或删除菜单后输入订单号进入图1的增、删、改界面，新增时订单编号自动产生，更新时订单编号不能修改。订单的明细记录在增、删、改界面可进行删除或添加处理，要添加时通过鼠标定位在编辑区按右键选择添加功能，然有会弹出一个产品列表来供操作者选择，材料代码和材料名称及单价是通过选择后自动添加的，不能人工修改，操作者只能修改订单数量，要删除时也通过鼠标定位在编辑区的某产品上按右键选择删除功能即可。打印版面通过打印模板定制并打印到打印机、导出版面也通过excel模板定制并输出到excel文件。其他说明： 1、用户表和产品数据表本次不变，订单功能开发仅仅是引用这些数据。
2、暂不考虑其它特殊业务逻辑和权限，如：不写日志、功能按钮不根据权限加以屏蔽。 功能界面情况如下： 图1：增、删、改界面 图2：查询界面 功能点分析： 1、首先我们来确定本功能涉及到哪些用户数据（ILF,EIF）因为新增需求是订单管理，故订单信息属于一个，另外在需求中提到用户表和产品数据表本次不变，订单功能开发仅仅是引用这些数据，所以用户信息和产品信息也是系统的ILF 或EIF，只不过本次新增需求时不计算它的ILF或EIF功能点，因为它没有改变，相信引用它的方式与以前一样，但在EI、EO、EQ中引用需要考虑其FTR复杂度。另外，需求又要求打印和导出需要使用版面模板，故应该有三个模本文件。订单类型没有提及需要动态从系统内部获取，根据一般经验应该是一个在程序中做死的下拉选择列表，到此这个新增需求涉及的ILF,EIF应为如下内容：用户数据列表 文件描述
软件项目的规模估计历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏以及一些人为错误，导致软件项目的规模估计往往和实际情况相差甚远。因此，估计错误已被列入软件项目失败的四大原因之一。 软件工程师经常会被问到，编一个什么什么样的软件需要多长时间、多少钱。面对这个问题，有不少人很犯难，因为，第一用户的需求太不具体，第二，自己缺乏一个科学的估计方法。下面是几种软件项目规模的估计方法。 概念介绍 先介绍一个衡量软件项目规模最常用的概念--LOC(Line of Code)，LOC指所有的可执行的源代码行数，包括可交付的工作控制语言（JCL：Job Control Language）语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。一代码行（1LOC）的价值和人月均代码行数可以体现一个软件生产组织的生产能力。组织可以根据对历史项目的审计来核算组织的单行代码价值。 例如，某软件公司统计发现该公司每一万行C语言源代码形成的源文件（.c和.h文件）约为250K。某项目的源文件大小为3.75M，则可估计该项目源代码大约为15万行，该项目累计投入工作量为240人月，每人月费用为10000元（包括人均工资、福利、办公费用公滩等），则该项目中1LOC的价值为： （240×10000）/150000＝16元/LOC 改项目的人月均代码行数为： 150000/240=625LOC/人月 方法一、Delphi 法 Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，但专家"专"的程度及对项目的理解程度是工作中的难点，尽管Delphi技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其它模型的输入时特别有用。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种软件相关经验人的参与，互相说服对方。 Delphi法的步骤是： 1、协调人向各专家提供项目规格和估计表格； 2、协调人召集小组会各专家讨论与规模相关的因素； 3、各专家匿名填写迭代表格； 4、协调人整理出一个估计总结，以迭代表的形式返回专家； 5、协调人召集小组会，讨论较大的估计差异； 6、专家复查估计总结并在迭代表上提交另一个匿名估计； 7、重复4-6，直到达到一个最低和最高估计的一致。 方法二、类比法 类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。 其基本步骤是： 1、整理出项目功能列表和实现每个功能的代码行； 2、标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不够的地方； 3、通过步骤1和2得出各个功能的估计值；
功能点估算(CMMI-FP)含例子 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下： ?功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法，则误差会比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示，首先大家应该了解功能点估算法的使用步骤。
一、功能点估算法识别项目范围和数据复杂度 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下： ?功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法，则误差会 比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示，首先大家应该了解功能点估算法的使用步骤。
功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要，如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 FP功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及，对软件项目范围的估算有很多种方法，常见的就是LOC代码行和FP功能点法，它们之间的区别和关系如下： 1、 FP功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高，假如这个时候使用LOC代码行估算法，则误差会比较大。 2、使用FP功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法与软件开发技术密切相关。 3、 FP功能点法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算的。 4、通过一些行业标准或企业自身度量的分析，FP功能点估算法是可以转换为LOC代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测，在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同，因此在项目结束时还需要对项目的范围情况进行估算，这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 在本文中将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础与大家进行讲解。如下图所示，首先大家应该了解功能点估算法的使用步骤。 功能点估算的步骤 1、识别功能点的类型。 2、识别待估算应用程序的边界和范围。 3、计算数据类型功能点所提供的未调整的功能点数量。
Primavera软件系统中的功能点方法 与软件研发项目规模成本估算 上海普华科技发展有限公司胡晓俊 Primavera系统中的功能点估算方法概述 功能点估算的概念 功能点估算是一种基于软件需求特性对软件项目的规模进行估测的方法。1979年IBM公司的Alan Albrech首先开发了计算功能点的方法，这种方法是通过评估和计量软件产品所需的内部基本功能和外部基本功能数目，再根据技术复杂度因子（权重）对这些软件功能计数进行量化，得到软件研发项目规模的最终结果。并且这个结果与软件的成本估算有着密切的关系。另外功能点这种估算方法与实现产品所使用的编程语言和技术没有关系，可以用于各种软件开发项目的规模估算中，目前功能点的估算方法已经被广泛的认可在信息系统、数据库密集型、4GL应用系统开发的规模测量中。 功能点的估算有两个目的：第一是作为软件规模的测量、对比和分析（如软件度量方法）的基础；第二，也是更重要的目标，是作为软件成本估计模型的输入，软件的成本估计则是基于功能点和工作量之间的经验成本估计关系（CER）进行的。 Primavera系统是一个应用于多行业的企业级项目管理的综合平台，主要应用于企业的多项目时间进度的管理、资源角色管理、费用成本管理、沟通管理、综合管理等项目管理领域。功能点估算的功能可以在Primavera系统Project Management组件中的一个自上而下估算的工具中实现。这个工具只是整个Primavera系统中的一小部分，但它将自上而下估算的方法和功能点估算的方法演绎成可实际操作应用的步骤， 功能点估算的过程 功能点的估算可以划分为三个步骤：统计未调整的功能点计数（UFP）、统计总影响度（TDI）和计算最终调整功能点计数（FP）。其中最终调整功能点计数就是我们功能点估算的最终结果。它是用来度量软件产品功能的标准单位，并可作为软件研发项目规模成本估算的基础。功能点的计算公式为：FP = UFC×TCF，TCF称为技术复杂度因子，是由总影响度TDI计算出来的：TCF = 0.65 + 0.01×TDI。因此功能点的计算公式也可以表示为：FP = UFC×（0.65 + 0.01×TDI），如下图所示。
13.1 估算软件规模 13.2 工作量估算 13.3 进度计划 13.4 人员组织 13.5 质量保证 13.6 软件配置管理 13.7 能力成熟度模型 在经历了若干个大型软件工程项目的失败之后，人们才逐渐认识到软件项目管理的重要性和特殊性。事实上，这些项目的失败并不是由于从事软件开发工作的软件工程师无能，正相反，他们之中的绝大多数是当时杰出的技术专家。这些工程项目的失败主要是因为管理不善。 所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。 软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。为了估算项目的工作量和完成期限，首先需要估算软件的规模。 13.1 估算软件规模 13.1.1 代码行技术 代码行技术是比较简单的定量估算软件规模的方法。这种方法依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。当有以往开发类似产品的历史数据可供参考时，用这种方法估计出的数值还是比较准确的。把实现每个功能所需要的源程序行数累加起来，就可得到实现整个软件所需要的源程序行数。 代码行技术的主要优点是，代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。代码行技术的缺点是：源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理；
用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。为了克服代码行技术的缺点，人们又提出了功能点技术。 13.1.2 功能点技术 功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点（FP）为单位度量软件规模。 1. 信息域特性 功能点技术定义了信息域的5个特性，分别是输入项数(Inp)、输出项数(Out)、查询数(Inq)、主文件数(Maf)和外部接口数(Inf)。下面讲述这5个特性的含义。 2. 估算功能点的步骤 举例：用3个步骤，可估算出一个软件的功能点数（即软件规模）。 （1）计算未调整的功能点数UFP (2) 计算技术复杂性因子TCF （3）计算功能点数FP 13.2 工作量估算 软件估算模型使用由经验导出的公式来预测软件开发工作量，工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月（pm)。支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适用于所有类型的软件和开发环境。 注：简要介绍：静态单变量模型、动态多变量模型、COCOMO2模型 13.3 进度计划 不论从事哪种技术性项目，实际情况都是，在实现一个大目标之前往往必须完成数以百计的小任务（也称为作业）。这些任务中有一些是处于“关键路径”（回顾之前相关知识）之外的，其完成时间如果没有严重拖后，就不会影响整个项目的完成时间；其他任务则处于关键路径之中，如果这些“关键任务”的进度拖后，则整个项目的完成日期就会拖后，管理人员应该高度关注关键任务的进展情况。 一个有效的软件过程应该定义一个适用于当前项目的任务集合。一个任务集合包括一组软件工程工作任务、里程碑和可交付的产品。
软件项目规模估计方法介绍 软件项目的规模估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏以及一些人为错误，导致软件项目的规模估算往往和实际情况相差甚远。因此，估算错误已被列入软件项目失败的四大原因之一。 软件工程师经常会被问到，编一个什么什么样的软件需要多长时间、多少钱。面对这个问题，有不少人很犯难，因为，第一用户的需求太不具体，第二，自己缺乏一个科学的估计方法。这里向大家介绍几种软件项目规模的估计方法。 概念介绍 先介绍一个衡量软件项目规模最常用的概念--LOC(Line ofCode)，LOC指所有的可执行的源代码行数，包括可交付的工作控制语言（JCL：Job ControlLanguage）语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。一代码行（1LOC）的价值和人月均代码行数可以体现一个软件生产组织的生产能力。组织可以根据对历史项目的审计来核算组织的单行代码价值。 例如，某软件公司统计发现该公司每一万行C语言源代码形成的源文件（.c和.h 文件）约为250K。某项目的源文件大小为3.75M，则可估计该项目源代码大约为15万行，该项目累计投入工作量为240人月，每人月费用为10000元（包括人均工资、福利、办公费用公滩等），则该项目中1LOC的价值为： （240×10000）/150000＝16元/LOC 改项目的人月均代码行数为： 150000/240=625LOC/人月 方法一、Delphi 法 Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别，但专家"专"的程度及对项目的理解程度是工作中的难点，尽管Delphi技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其它模型的输入时特别有用。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种软件相关经验人的参与，互相说服对方。 Delphi法的步骤是： 1、协调人向各专家提供项目规格和估计表格； 2、协调人召集小组会各专家讨论与规模相关的因素； 3、各专家匿名填写迭代表格； 4、协调人整理出一个估计总结，以迭代表的形式返回专家； 5、协调人召集小组会，讨论较大的估计差异； 6、专家复查估计总结并在迭代表上提交另一个匿名估计；
几种常见的软件规模度量方法的对比 在软件研发成本度量（包括估算与测量）方面，对于软件规模本身的评价是首要任务。根据软件行业的实践，目前评价软件规模的方法主要分为两种：基于业务视角和基于开发视角。基于业务视角的方法是从用户角度出发，与软件开发技术无关，如：功能点、故事点、用例点、对象点等方法；基于开发视角的方法是从开发者角度出发，如：基于软件源代码行、数据库表、函数数量等方法。 基于开发视角的软件规模评价的方法，优点是操作简单、实施容易，但不容易在项目干系人之间达成一致，往往会引起较多的分歧。基于开发视角的评价方法虽然在实际工作中也有着普遍的应用，但更多地局限于软件开发团队内部。如果要在业务部门与开发部门、甲方与乙方等外部组织约定软件开发的工期或费用等关键项目目标，则需要从业务视角出发，对软件项目规模进行标准、一致的评价与估算。而且，在系统初始阶段，用户功能需求是唯一真正可以得到的信息。任何程序大小或代码行数的猜想实际上都是从系统要提供的功能性推演出来。 下表展示了几种常用的软件规模度量方法的对比，可以看出，功能点方法最优。 软件规模度量方法对比 分类比对项目功能点对象点用例点故事点代码行 方法有效性业务价值分析★★★★★★★★★★产能分析与评 估 ★★★★★★★★★★★★项目早期估算★★★★★★★★★★★项目中后期估 算 ★★★★★★★★★★★★项目范围管理★★★★★★★★★★★★★★团队绩效评价★★★★★★★★★★行业基准比对★★★★★★★★ 应用难度方法学习难度★★★★★★★★★★★★★方法导入成本★★★★★★★★方法应用一致 性 ★★★★★★★★★ 从美国人Allan J.Albrecht在20世纪70年代末提出功能点方法以来，功能点在软件行业的应用与实践已超过30年，在Albrecht的功能点模型基础之上，经过进
CMMI之功能点估算法---内部逻辑文件和外部接口文件 2008-01-24 作者：张瑾 关键词：CMMI、软件工程、MA、度量、PP、项目计划、项目估算 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要，如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 FP功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及，对软件项目范围的估算有很多种方法，常见的就是LOC代码行和FP功能点法，它们之间的区别和关系如下： 1.FP功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的 准确性比较高，假如这个时候使用LOC代码行估算法，则误差会比较大。 2.使用FP功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法与软件开 发技术密切相关。 3.FP功能点法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估 算的。 4.通过一些行业标准或企业自身度量的分析，FP功能点估算法是可以转换为LOC代码 行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测，在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同，因此在项目结束时还需要对项目的范围情况进行估算，这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 在本文中将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础与大家进行讲解。如下图所示，首先大家应该了解功能点估算法的使用步骤。
电子政务工程软件项目费用构成及概算方法 （V1.0） （征求意见稿） 为规范电子政务工程项目软件的价格行为，维护价格公平竞争，同时为电子政务软件项目进行经费概算提供科学可信的依据，广东软件行业协会组织有关专家和企业，经过多次研究和修订，提出以下电子政务工程软件项目费用构成及概算方法。 一、名词解释 开发阶段：开发阶段是指从软件项目启动到项目实施前的这一时间段。因此，开发阶段的工作包括详细需求分析、系统设计、编码、测试等方面的工作。 实施阶段：实施阶段是指软件项目从实施开始到项目正式验收的这一时间段。因此，实施阶段的工作包括系统安装、系统调试、用户培训等方面的工作，但不包括各实施点的本地化开发工作。 运行维护阶段：运行维护阶段是指从软件项目正式验收到合同规定的一年项目维护期结束的这一时间段。因此，维护阶段的工作包括系统在维护期内所需要提供的原系统完善性修改和服务等工作（不包括新增需求和原功能的重大变更）。 功能点：功能点是对软件功能和大小的间接度量单位，一般通过必须和用户交互的情况的数目来测算程序工作量的大小。功能点分析法是目前国际上软件行业普遍接受的软件项目规模度量模型。 成本系数：成本系数是指完成某个功能点（FP）的规定活动所需要
投入的人工时，因此成本系数的单位为：人工时/FP。如开发阶段的成本系数，则是指一个功能点（FP）需要完成“详细需求分析”、“系统设计”、“编码”和“测试”等工作所需要投入的人工时。其他如实施阶段成本系数、运行维护阶段成本系数的定义以此类推。 软件人员月人工费用：软件人员月人工费用是指一个软件人员工作一个月平均需要的所有成本开销（包括工资、奖金、福利、办公成本、国家各种税费、管理费用等等）及软件企业合理利润的总和。 二、软件项目费用构成 电子政务软件项目的费用构成因素很多，为准确描述，我们依据软件工程理论，从角色和项目阶段两个维度来描述项目的费用构成。从角色维度来看，电子政务工程项目建设中主要包括建设方、承建方、第三方测试机构和监理方四个主体；从项目阶段维度来看，可以分为前期咨询、开发、实施、验收、维护五个阶段。用一个二维表来表示角色、项目阶段和项目费用的对应关系，如下表所示。 电子政务软件项目费用构成表
软件规模估算的假设和思路： ?软件的规模和其外延成正比 l外延包括: 功能, 数据, 用户操作界面数, 显示界面数等等 ?不同的功能点实现的困难度不同, 但从整个项目来说, 平均的困难度差不多 ?规模估算的目标：是决定工作量的大小。对于成本模型，规模是计算软件项目的工作量、成本和进度的主要输入 ?规模估算的责任者：程序员、软件工程师、系统分析员负责决定软件项目的规模 ?规模估算的入口准则:在规模估算之前，软件功能需求必须被定义。在项目早期定义需求可能是非常困难任务。然而，在对需求一无所知的情况下，精确的估算出项目的成本和进度是不可能的。如果知道部分需求，那么估算基于已知的需求并且相信每一个人都相信估算仅仅是基于那些已知的需求，如果使用了增量或演进的开发策略，那么估算基于增加的已定义需求。 ?规模估算输入:软件需求说明书（SRS） 历史规模数据 ?规模估算活动: 软件产品规模通常以代码行（SLOC）或千代码行（KSLOC）度量。软件应该以全新代码或者合并新旧代码进行开发。对已存在代码接口的估算与新代码的估算是同等重要的。已存在代码借口通常需要与开发新代码相同的工作量。 ?软件产品规模估算应该主要基于历史数据和经验。历史规模数据可以从组织软件过程数据库中找到。而且，两个或更多的具有类似经验的软件工程师应该开展自顶向下/自底向上规模估算，步骤如下： A) 基于定义每个计算机软件模块的需求开发系统的高级架构图 B) 基于每个计算机软件模块开发功能WBS C) 根据相似项目经验和历史数据，为每一个软件模块手工估算出最底层（自底向上）可能详细的代码行或功能点，规模估算工具可以作为第二个输入 D) 估算出期望的规模加上标准偏差，即：规模的最低值和最高值来反映名义值的不确定性。在项目的早期阶段，最低和最高估算结果之间的范围可能是30-50%，例如：概念阶段。如果缺乏经验或有较高的技术风险，范围将会更大 E) 具有类似经验的软件工程师应该评审并优化估算结果直至达成一致意见。经验表明，规模估算经常偏低，故最低规模估算结果应该给与特别审查 一些规模估算的标准方法和工具如下：Wideband Delphi技术、Pert Sizing技术、功能点方法、类比法和自动化规模估算工具。这些方法的详细描述在前面功能估算和预算制定中已经提到。建议至少使用两种方法进行规模估算，不要依赖于任何一种方法
功能点估算法识别项目范 围和数据复杂度 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下： ?功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法，则误差会比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC 代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示，首先大家应该了解功能点估算法的使用步骤。
计算机系统软件成本构成及估算方法 随着知识经济、信息时代的来临，计算机软件业迅猛发展。商品化、资本化、资产化的计算机软件的价值评估的社会需求也日益增多，而且有越来越多的趋势。由于系统软件通常是一些规模大、复杂程度高的人一机系统，因此，系统软件的开发、使用、维护、管理的过程，是一个非常复杂的系统工程，需要有巨大的人力、物力、财力资源，需要各种计算机软、硬件的支持。这一特点是在系统软件评估中应予充分考虑的，也是从成本途径评估系统软件价值时应予着重关注的。据统计，软件成本在软、硬件总成本中的份额，已从50年代的百分之十几，上升到近期的百分之七八十，而且还在持续上升。软件成本中的开发成本和维护成本的比例，也从50年代的接近1：1，达到了近期的1：2。系统软件开发成本和维护成本在整个生命周期中份额。 本文对上表的数字作了部分调整。主在维护阶段剔除了完善
性维护成本。这一项成本不应列入委托评估系统软件的本次价值评估。这样，开发、维护成本在整个生命周期中的份额也相应发生了变化。 一、系统软件的成本构成 系统软件的成本作为一个经济学范畴，应反映软件产品在其生产过程中所耗费的各项费用，为原材料、燃料、动力、折旧、人工费、管理费用、财务费用待项开支的总和。 从财务角度来看，列入系统软件的成本有如下的项目：（1）硬件购置费如计算机及相关设备的购置，不间断电源、空调器等的购置费。（2）软件购置费，如操作系统软件、数据库系统软件和其它应用软件的购置费。 （3）人工费，主要是开发人员、操作人员、管理人员、的工资福利费等。（4）培训费。（5）通讯费，如购置计算机网络设备、通讯线路器材、租用公用通讯线路等的费用。（6）基本建设费，如新建、扩建机房、购置计算机机台、机柜等的费用。（7）财务费用。（8）管理费用，如办公费、差旅费、会议费、交通费。（9）材料费，如打印纸、包带、磁盘等的