功能点估算案例 下面以员工管理系统为例，详细说明如何利用功能点估算法计算业务复杂度。 在员工管理系统中添加一个员工的资料，会使用到员工的一般信息、教育情况、工作经历和家属信息。员工隶属于某个部门，在本系统中会有一个对部门进行维护的功能。员工的工资则由另外一个财务系统提供。因此，其用例图如下所示： 图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. 计算调整后的功能点数量。
功能点估算法介绍及 应用
一、功能点估算法识别项目范围和数据复杂度 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在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应为如下内容：用户数据列表 文件描述
整理的功能点计算法
功能点描述 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要，如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及，对软件项目范围的估算有很多种方法，常见的就是LOC代码行和FP功能点法，它们之间的区别和关系如下： 1、FP功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高，假如这个时候使用LOC代码行估算法，则误差会比较大。 2、使用FP功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法与软件开发技术密切相关。 3、FP功能点法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算的。 4、通过一些行业标准或企业自身度量的分析，FP功能点估算法是可以转换为LOC代码行的。在项目刚开始的时候进行功能点估算可以对项目的范围进行预测，在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同，因此在项目结束时还需要对项目的范围情况进行估算，这个时候估算的结果才能最准确反映项目的规模。 功能点的公式： ●功能点的原始计算公式：FP Count =UFP * VAF ●新开发项目有时新开发的软件项目也需要与其他现存的软件系统进行整合，例如：一个企业新开发的MIS 内部管理系统经常会与财务系统进行整合。这个时候除了考虑本身项目的功能点个数外，还要考虑系统整合或数据迁移部分的工作量，因此其功能点计算公式如下：FP Count =（UFP+CFP）* VAF ●二次开发的项目有时新开发的软件项目是在原有基础上进行二次开发的，只是为了增加一些新的功 能，因此其功能点计算公式如下：FP Count = ADD * VAF
功能点估算(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），如下图所示。
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）需要完成“详细需求分析”、“系统设计”、“编码”和“测试”等工作所需要投入的人工时。其他如实施阶段成本系数、运行维护阶段成本系数的定义以此类推。 软件人员月人工费用：软件人员月人工费用是指一个软件人员工作一个月平均需要的所有成本开销（包括工资、奖金、福利、办公成本、国家各种税费、管理费用等等）及软件企业合理利润的总和。 二、软件项目费用构成 电子政务软件项目的费用构成因素很多，为准确描述，我们依据软件工程理论，从角色和项目阶段两个维度来描述项目的费用构成。从角色维度来看，电子政务工程项目建设中主要包括建设方、承建方、第三方测试机构和监理方四个主体；从项目阶段维度来看，可以分为前期咨询、开发、实施、验收、维护五个阶段。用一个二维表来表示角色、项目阶段和项目费用的对应关系，如下表所示。 电子政务软件项目费用构成表
功能点估算法识别项目范 围和数据复杂度 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下： ?功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法，则误差会比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC 代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。 功能点分析的步骤 本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示，首先大家应该了解功能点估算法的使用步骤。
功能点估算(CMMI-FP) 功能点估算法是软件项目管理众多知识中比较有技术含量的一个。在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。 一、功能点估算法的特点 项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。它们之间的区别和关系如下： ?功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法，则误差会比较大。 ?使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 ?功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。 ?通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。 在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。 二、功能点分析的步骤 本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示，首先大家应该了解功能点估算法的使用步骤。
IFPUG 功能点估算基本方法 Function Point Estimation 功能点估算是一种用来估算项目大小的技术。 项目经理从已经界定的软件范围开始，并根据该陈述将软件分解为可以被单独估算的功能单元，然后估算每一个功能的FP值。这种分析方法是按照功能为估算单元进行分解，同样如果以其它元素作为估算单元，例如类、对象、业务过程，以下都以功能分解进行讨论。 注意：功能单元是指分解到的最小可估算单元。 FP值是按照经验，使用复杂度参数进行估算调整过的量化的数值。 估算的基本过程： a) 界定项目范围； b) 分解项目到可以被估算的最小功能单元； c) 识别功能单元的类型，估算复杂度； d) 计算总体系统特征值； e) 计算调整因子； f) 应用公式计算FP值。 1. 界定项目范围 界定项目范围这次不讨论。 2. 分解项目到可以被估算的最小功能单元 系统用5种信息域特征进行描述： 事务（Transaction）： 外部输入( External Input EI) 外部输出（External Output EO） 外部查询（External Inquiry EQ） 数据存储： 内部逻辑文件（Internal Logical File ILF） 外部接口文件（External Interface File EIF）。 内部文件（ILF）指每个逻辑主文件（即数据的一个逻辑组合，它可能是某大型数据库的一部分或者是一个独立的文件），例如数据库表。注意不是一个数据库表就是一个ILF，例如合同数据可以包括合同信息、合同条款、合同付款计划。 外部接口：所有机器可读的接口，是不由本系统维护的逻辑文件，是其它系统的ILF。例如：web service取回的数据，一个人工维护的Excel表格。 3. 估算功能点的复杂度 数据元素类型(Data Element Types DET)是一个用户可识别的、唯一性的、非递归的域。 记录元素类型(Record Element Types RET)是ILF或者EIF中用户能够识别的数据元素小组。 档案类型（File Types Referenced FTR）是被引用或更新的内部逻辑档案。 交易类信息域(EI、EQ、EO)的复杂程度取决于这个交易牵涉到的数据元素类型数量，以及被引用或者更新的档案文件类型的数量。 数据存储(EIF、ILF)的复杂程度取决于这个数据的逻辑组合包含了多少类记录元素类型，以及包含了多少数据元素类型。例如合同数据包括了合同信息、合同条款、合同付款计