软件项目中的功能点估算法.docVIP

原理 Function Point Estimation 功能点估算是一种用来估算项目大小的技术。 功能点是对软件功能和规模的间接定量测量，它基于客观的外部应用接口和主观的内部应用复杂度以及总体的性能特征。 功能点法和专家法估算最大的不同点在于对估算规模的细化的定量分析上面．我们在用专家法估算的时候往往会直接去估算工作量，或在规模的估算中掺杂了生产率的数据，导致估算数据出现问题．专家法估算虽然有时候也很准确，但不能提升为组织级可以参考和借鉴的同样规则．其实专家法的估算要做准确也是遵循了功能点法估算的思路，在考虑一个软件功能究竟涉及到哪些操作，涉及到多少数据文件的存在，每个操作需要访问哪些数据文件等相关问题．只是这些想法停留在专家头脑里面而没有量化出来． 我们的预测，分析和决策能力要提升，就必须对我们的经验进行模型化和定量分析．功能点法正好就起到了这个作用．其实功能点发也有不完善的地方，这可以根据我们项目实际的使用情况去不断的改进． 功能点发进行估算的时候具体过程是： 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复杂度的计算： 信息域数据估算完成后可以开始考虑调整因子： 调整因子是一种补偿机制，即通过五个信息域和复杂度都还没有办法考虑到的因素就应该做为调整因子．如同样一个软件系统一种是系统要支持分布式和自动更新，而另一种是不考虑这种需求，如果不考虑调整因子这两者的规模是一样的，但很明细第一种情况复杂度和规模都会更大些． 有了调整因子后最终可以得到调整后的功能点数: AFP(调整后功能点)= UFP (未调整功能点数目)* AF (影响因子) 实例 需求：实现一个订单的录入，更新，删除和查询功能．订单信息是指一个用户订购的公司产品的情况．其中订单头包含了具体的类型，订购时间，发运地址，客户名称等信息．订单明细包含了订购的具体产品的数量的情况． 假设： 1.用户表和产品数据表已经建立，本次订单功能开发仅仅是引用和取这些数据． 2.暂不考虑其它特殊业务逻辑和权限 功能界面情况： STEP1:计算出EI,EO和EQ事务功能 举例：对于订单保存功能，项目自我约定对于组合框DET算2,对于GRID的DET算3.其余界面控件DET都算1,所以可以数出DET数目为15.再来考虑FTR数目，这里需要操作订单数据文件，客户数据文件和产品数据文件FTR数应该算3. STEP2:计算出ILF和EIF事务功能 1.这里订单文件只算一个DET，但后台数据表会涉及到两个数据表．由于订单头和订单明细有关联关系，所以这里RET取2. 2.客户文件和产品文件虽然不是外部系统文件，但本次开发的功能并不需要再去设计该数据文件和数据表，所以这里把其作为EIF来处理． STEP3:根据对应表计算各个信息域复杂度的情况． 最终的估算情况如下： 最终的未调整的功能点数目为:61 调整因子在这里不再举例说明了,如项目调整因子为1.08，则最终功能点数为： AFP = 61*1.08 = 66. 还有些没有细化考虑的，如具体的DET数量的计算规则等，还请指正．