手工软件估计方法-功能点方法.ppt

——《软件项目估计》《《软件项目管理软件项目管理》》课程课程￿ ￿替换替换内容内容北方民族大学北方民族大学北方民族大学北方民族大学 计算机科学与工程学院计算机科学与工程学院计算机科学与工程学院计算机科学与工程学院陶铮陶铮陶铮陶铮 2008200820082008年年年年10101010月月月月开头的话￿我们经历了软件项目的任务分解，还预期了后续的软件集成，假设这些在技术上都是可行的，那么，我们该反思什么？￿这样看来，这个项目就在我们的掌握之中了？￿注意，此结论中的一个假设——成本是可以接受的￿此假设成立吗？￿我们的分解适合这个成本吗？软件项目估计在什么时候开始？￿软件项目管理者的第一个关键性任务，就是估算项目成本￿软件项目估计必须提前开始￿为了防范项目风险，适应市场竞争￿在获取足够的软件项目信息之前就要进行￿本章介绍——基于功能点法则的手工估计￿到目前为止，己有几千个项目在使用功能点度量￿基本的依据：功能点概念及其在软件估计中的作用○此法则十分普及，不仅能够估计成本费用，还能估计软件的规模、进度、工作量及质量什么是功能点？￿功能点，是基于应用软件的外部、内部特性以及软件性能的一种间接的软件规模的测量。

￿功能点与软件成本具有重大的成本估计关系（CER：Cost Estimating Relationship）功能点从何而来？￿来自对软件的规模的度量单位￿“规模”是通过功能点数来测量的，而功能点又是通过测量规格说明而获得的￿这里“规模”实际上表示一种更明确的属性，即软件的功能性什么是规格说明？￿示例：“AquaLush灌溉系统”中的规格说明￿系统原理：用定时器管理灌溉（喷水系统）——按照固定的时间间隔定时放水；采用土壤湿度传感器监测土壤情况——已经很湿，就不喷水，否则，如果土壤很干燥，灌溉将持续进行，直到土壤达到足够的湿度规格说明-功能需求功能需求1.1.设置参数设置参数￿AquaLush必须允许设置其模式（手动或自动）必须允许设置其模式（手动或自动）￿AquaLush必须允许设置当前时间必须允许设置当前时间￿AquaLush必须允许设置灌溉发生的日期和时间，这被称为灌溉时必须允许设置灌溉发生的日期和时间，这被称为灌溉时间￿AquaLush必须允许设置控制灌溉的湿度，这被称为临界湿度必须允许设置控制灌溉的湿度，这被称为临界湿度￿AquaLush必须允许设置灌溉中使用的最大用水量，这被称为水分必须允许设置灌溉中使用的最大用水量，这被称为水分配量。

配量2.2.一般操作一般操作￿AquaLush必须允许在自动或手动模式下进行操作必须允许在自动或手动模式下进行操作￿AquaLush必须监视灌溉中的用水量必须监视灌溉中的用水量￿AquaLush必须检测阀门和传感器故障必须检测阀门和传感器故障￿AquaLush必须在遇到阀门和传感器故障时尽可能继续正常工作必须在遇到阀门和传感器故障时尽可能继续正常工作￿AquaLush必须在接到指令后报告故障组件及其位置必须在接到指令后报告故障组件及其位置3.3.手动模式操作手动模式操作￿AquaLush必须允许打开或关闭各个阀门必须允许打开或关闭各个阀门￿AquaLush必须提供有关手动灌溉的数据必须提供有关手动灌溉的数据￿……￿上述的功能规格描述，是计算功能点的基础￿结论：软件规模可以定义为￿预期的代码行数——来自传统的经验，但现在不用了￿预期的功能点数——来自系统分解后的子产品的规格说明￿与功能点相似的估算基准，还有：￿对象点、故事点、用例点、Web对象点等￿这些新度量的经验法则也正在发展之中￿示例：灌溉系统的用例图示例：灌溉系统的用例点￿用例2：设置灌溉参数￿基本流程：1.操作人员设置灌溉时间、水分配量或临界湿度。

2.AquaLush验证新的设置3.AquaLush记录并确认新的设置￿扩展：￿2a设置无效○2a1.AquaLush将无效设置通知操作人员○2a2.操作人员调整设置○2a3.AquaLush检查设置，然后恢复基本流程，或者返回到步骤2a1￿那么，基本掌握了功能点之后，怎么估算软件的成本？￿本章的核心内容：基于功能点经验法则的软件手工估算方法￿经验法则是我们的基本依据——从几千个项目中得出的一系列经验法则——这些项目主要采用传统的软件开发“瀑布”模型外部式样外部式样于是，我们认识到所谓外部样式，指：需求文档、设计文档、源代码、测试用例等软件的描述手工软件估计方法有三种：￿利用经验法则的手工项目级估计；￿利用比率和百分比的手工阶段级估计；￿利用WBS（Work Breakdown Structure，工作分解结构）的手工活动级活动级估计￿手工估计方法适用于以下场合：￿需求明确前的早期估计；￿项目不大——编程人员不多；￿项目的风险不大——不会对业务产生重要影响￿手工估计的误差问题——如果过分乐观，则会低估了真实成本和实际进度◇ 75%以上的手工估计的偏差超过35%，成本和进度的最大偏差均超过50%。

本课件内容——6.3 基于功能点度量的经验法则6.3.1关于功能点6.3.2功能点规模估计的经验法则6.3.3进度、资源、成本的经验法则6.3.4基于活动的成本分析经验法则参考书籍￿[美]琼斯著，刘从越等译，《软件项目估计(第2版)》，电子工业出版社，2008-03￿教师提供第6章电子版注：本课件采用了《软件项目估计》一书中的章节码功能点估算（FPE：Function Point Estimation ）功能点分析法（FPA：function point analysis）功能点概念的起源￿1974年，IBM 的Allan J.Albrecht为开发一种改进的软件项目规模估计、项目估计和测量方法而创立的功能点分析方法￿随后，IBM公司公布了这一成果——“基本功能点度量”￿近年来，在国外的应用普及很快￿印度软件发展非常快——外包！95％以上的公司都是用功能点￿日本都在用功能点进行度量￿我国一些大的公司和从事外包的公司正在转向￿参考资料参考资料-1：采用功能点是必然之路！：采用功能点是必然之路！￿发布时间：2007.04.23 11:57 来源：赛迪网 作者：徐培炎￿ 黄相民老师和汪浩老师做客赛迪网嘉宾聊天室，谈“功能点估计”￿参考资料-2：CMMI之功能点估算法---内部逻辑文件和外部接口文件○功能点分析方法基本思想￿以应用程序的不随编程语言而改变的外部属性为依据，来估计应用程序的规模。

￿软件的5种外部属性（类型）：1.应用程序的输入2.应用程序的输出3.用户查询4.应用程序维护的逻辑文件5.与其他软件的接口￿功能点就是上述的5种外部属性加权后的总和 系统用5种信息域特征进行描述： 1. 事务（Transaction）： 1）外部输入( External Input EI) 2）外部输出（External Output EO） 3）外部查询（External Inquiry EQ） 2.数据存储： 1）内部逻辑文件（Internal Logical File ILF） 2）外部接口文件（External Interface File EIF）软件度量的作用——10个目标常用的5个目标1.度量能用于软件合同评价；2.度量能用于与客户进行交流；3.度量能用于测量软件质量；4.度量能用于测量软件生产率；5.度量能用于测量任何软件任务或活动，而不只是测量编码；1.度量能用于大规模的统计分析；2.度量能用于价值分析3.度量能用于测量使用任何已知的编程语言编写的软件；4.度量能用于测量使用各种不同组合的编程语言的软件；5.度量能用于测量所有种类的软件（实时软件、MIS软件、系统软件等）；6.3.2.1需求分析完成之前的规模估计6.3.2.3估计源代码规模6.3.2.4估计纸质交付产品的规模6.3.2.5估计蔓延的用户需求的规模6.3.2.6估计测试用例数6.3.2.7估计软件潜在缺陷数6.3.2.1需求分析完成之前的规模估计￿采用功能点规模估计方法，可以在需求完成前得到近似的功能点总数。

￿基本方法￿分类：把需求描述按照范围、种类、类型划分￿按类猜测软件的近似规模，然后各类的估计值相加，再计算该总和值的2.35次幂即可范围范围范围范围种类种类种类种类类型类型类型类型1子程序1个人软件1非过程软件2模块2共享软件2 Web小程序3可重用模块3学术软件3批处理软件4可抛弃原型4内部单点使用4交互式软件5演化原型5内部多点使用5交互式的图形界面或Web页面6独立程序6民用合同项目6批处理数据库7系统组件7分时处理软件7交互式数据库8系统发布8军用服务8客户机服务器软件9新系统9网络应用9数学计算软件10复合系统10租用软件10系统软件11捆绑软件11通信软件12市场管销12过程控制软件13外包合同13可信系统软件14政府合同14嵌入式软件15军用合同15图像处理软件16多媒体软件17机器人软件18人工智能软件19神经网络软件20混合型软件表表6.7 范围范围 种类、类型值示例种类、类型值示例操作步骤①根据待估计项目的范围、种类、类型的具体情况，分别确定范围、种类、类型的值；②将3个值相加得到和；③求和的2.35次幂￿示例：假设正在构建的一个软件的3个类别值是：○范围=6（独立程序）○种类=4（内部单点）○类型=8（客户机/服务器）○和=18○18的2.35次幂等于891。

￿结论，该软件的功能点总数约为891￿经验——客户机/服务器模式的应用程序的规模通常在1000个功能点左右的范围内，所以891个功能点并不是个糟糕的起点关于“IFPUG”￿上述计算规则，来自IFPUG4.1版￿什么是IFPUG?￿IFPUG是美国的一个功能点组织——国际功能点用户协会(The International Function Point Users‘ Group)￿http://www.ifpug.org/￿IFPUG読み方アイエフピーユージーIFPUG的主要工作￿修订规则￿平均每3年发布一次大修订，每年发布一次或两次小修订￿最常见的修订原因是增加了软件的新类型或新环境，如基于Web的应用程序或嵌入式应用程序￿出版物￿计算实用手册/Counting Practice Manual（CPM4.2.1） ￿给管理者的功能点价值手册/Function Points as Assets Reporting to Managers Manual ￿软件度量报告/Guidelines to Software Measurement ,Release1.1￿ …再示例￿一个军用软件项目，由表6.7：￿范围=9（新系统）￿种类=15（军用合同）￿类型=13（可信系统）￿和=37￿37的2.35次幂=4844，该应用程序的功能点总数约等于4844。

￿经验——系统级军用软件项目的规模通常在5000个功能点的范围内（或者更大），因此这种粗略的方法足以使人们意识到这个应用程序将不会是个小程序关于“范围”￿根据上述分类中的第一列——“范围”，也可粗略估计软件的规模，见表6.8￿为不同种类项目的规模“平均值”，假设每个功能点约等于100行逻辑源代码语句￿示例：作为复合系统的MS Office￿由文字处理软件、电子表格软件、数据库管理软件、图形处理软件、个人日程软件等几个（5个）独立的应用程序组成，且所有这些软件集成在一起，并能协同工作￿MS Office中每个独立的应用程序的规模均为3000～5000个功能点，加上可实现信息共享的OLE功能模块，总规模约为25000个功能点6.3.2.3估计源代码规模￿法则1：源代码规模估计，一个功能点=?行语句=320行基本汇编语句=213行宏汇编语句=128行C语句=107行COBOL语句=107行Fortran语句=80行PL/I语句=71行Ada语旬=53行C++语句=50行Java语句=15行Smalltalk语句6.3.2.4估计纸质交付产品的规模￿文档何其多？￿大型软件项目需生成50多种计划、需求、规格说明和用户文档。

￿大型军用项目的纸质文档的成本，远高于生成源代码的成本￿文档规模的估计￿10000个功能点或者说一百万行源代码语句左右的大型系统通常会产生大量的文档￿某些规格说明会多达60000多页￿少数100000个功能点左右的超大型系统的规格说明，其阅读时间居然会超出一个人的寿命，即一个人在他全部的职业生涯中每天用8小时读也无法读完！￿法则2：软件计划、规格说明和手册的规模估计￿软件项目相关的纸质文档总页数，约等于功能点数的1.15次幂￿切记！纸质文档对软件的成本和进度有非常大的影响，因此不能随意省略￿其实，LOC度量的一个主要问题就是忽略了软件的纸质交付产品的数量及软件文档所带来的高成本6.3.2.5 估计蔓延的用户需求的规模￿软件业的一个最大难题￿在初始需求阶段结束后如何处理新的需求和变化的需求？￿功能点度量在测量需求蔓延速率时非常有用￿软件合同和外包协议中已开始使用成本/功能点——可以在合同中写入关于后期增加需求时的费用要求——加入滑动成本的有关条款￿法则3：蔓延的用户需求的规模估计￿从设计阶段到编码阶段，蔓延的用户需求以平均每月2%的速率增长￿在软件应用程序的开发周期中，软件应用程序将平均增长至少15%。

￿例如：合同中可包含下述有关后续增加的新需求的成本条款初始的1000个功能点500美元/功能点合同签订3个月后增加的功能600美元/功能点合同签订6个月后增加的功能700美元/功能点合同签订9个月后增加的功能900美元/功能点合同签订12个月后增加的功能1200美元/功能点用户要求删除或推迟实现的功能150美元/功能点何为测试用例？示例：从用例到测试用例￿一个Web应用：网上电影管理￿电影数据库中包含了电影的列表、导演、演员和电影评论等信息￿电影数据库可以由“内容编辑”进行编写和更新， Web站点上的用户可以查找或读取这个数据库￿待测功能：1）内容编辑写数据库，2）网上冲浪者从数据库中查找电影电影数据库的用例图电影数据库的用例图￿从“用例”中创建“测试用例”￿从用户操作的场景出发，逐个分析事件过程中的各种情况，如：用例Search by Movie的“正常事件过程”（椭圆标记）描述为：￿测试用例编写还有…6.3.2.6估计测试用例数￿功能点度量在估计测试用例数时也非常有用，因为功能点分析的结构与测试所验证的对象的结构是相吻合的￿法则4：测试用例数估计￿生成的测试用例数约等于功能点数的1.2次幂。

￿注意：这条简单的经验法则估计的是各种类型测试的测试用例总数，因此请谨慎使用6.3.2.7估计软件潜在缺陷数￿法则5：软件潜在缺陷数估计￿新开发的软件项目的潜在缺陷数，约等于功能点数的1.25次幂￿对于改进软件项目的潜在缺陷数，约等于功能点数的1.27次幂￿注意：这里的潜在缺陷数是指下列5种主要交付产品中的Bug或错误的总和：1.需求2.设计3.代码4.用户文档5.Bad-fix，即修复错误的过程中引入的新错误￿美国的新项目开发过程中产生的软件缺陷的平均值见表6.10.缺陷来源缺陷数/功能点需求1.00设计1.25代码1.75文档0.60Bad-fix0.40合计5.00下一步是估计进度、资源、成本及其他有用的结果￿我们已经知道怎样利用经验法则，来估计功能点数，进而，还知道由功能点数可以估计需求蔓延、测试用例以及软件缺陷数等￿这些估计都指向了开发团队将要花费的时间、付出的成本以及配套的资源这就是下一步的工作：进度、资源、成本的估计6.3.3.1分配范围和生产率的基本原理6.3.3.2估计软件进度6.3.3.3估计软件人员数6.3.3.4估计软件开发的工作量6.3.3.1基本假设（分配范围和生产率的基本原理）￿这里的软件经验法则、手工估计方法等，都基于如下两个主要概念：￿分配范围（A范围）：指在某个软件项目中一个人所承担的工作量；￿生产率（P速率）：指在一小时、一周、一个月或一年等标准的时间周期内，一个人所能完成的工作量。

￿估计软件进度、资源和成本的原理￿对上述的分配范围和生产率，采取易于使用的工作产品的自然度量单位来计算￿度量单位有：功能点、源代码语句或单词、文档页等示例￿假设被估计的应用程序用C语言编码，规模为50000行源代码语句￿假设编程人员的平均分配范围是10000行源代码语句，则该项目需要5名编程人员￿假设编程人员的平均编码生产率为2000行C语句/月，那么项目将耗时：○5人×2000×5个月=50000行○需要25个人·月的成本以每人月工资6000美元计—— 5人×5个月×6000$=150000美元我国IT人员的价值￿北京地区的月工资（平均数）一般程序员一般程序员2000-4000元元中级程序员中级程序员4000-6000元元高级程序员高级程序员6000-8000元元需求分析员需求分析员需求分析员需求分析员8000-100008000-10000元元元元项目经理项目经理15000-25000元元6.3.3.2估计软件进度￿法则9：软件进度估计￿以月为单位的开发进度约等于功能点数的0.4次幂——分类参照表6.11￿本法则用于计算从需求开始直至第一次交付客户的大致时间￿本法则只是通用法则——军用软件通常要花费更多的时间，约为功能点数的0.45次幂。

○使用功能点估计进度是近年来所发现的功能点的又一新用途——目前还不能用于合同等重要商业用途6.3.3.3估计软件人员数￿法则10：软件开发人员数估计￿开发应用程序所需的人员数约等于功能点数除以150￿本法则估算的人数中包括软件开发人员、质量保证人员、测试人员、技术文档编写人员、数据库管理人员利项目经理￿本法则只是为更详细的人员分析提供了基础——如果注重编码、压缩管理、淡化分析和设计、减少文档作业，则可用500个功能点/人￿法则11：软件维护人员数估计￿修改应用程序所需的维护人员数约等于功能点数除以750（适用于Java等高级语言）￿本法则表明：一个人可以完成对软件的小更新，并维护约750个功能点￿另一条有意义的经验法则是：应用程序使用的年数约等于功能点数的0.25次幂￿法则12：软件开发工作量估计￿以人月为单位的工作量约等于软件开发进度乘以人员数6.3.3.4 估计软件开发的工作量￿法则9+法则10的混合法则￿假设项目的规模为1000个功能点￿用法则9，即取1000个功能点的0.4次幂，可计算出进度约为16个月；￿用法则10，即取1000个功能点除以150，可计算出全职人员约为6.6名；￿16个月乘以6.6个人等于106个人月，这就是此项目的工作量。

￿工作量的细化（经验法则）￿定义一个人月折合22个工作日￿每个工作日的工作时间为6小时，或者说每月的工作时间为132小时我们该回头检查了￿我们该回到合同中去，看看合同的金额应该如何？￿当然，如果按照规范的做法，这个悬念早就解决了￿教材中的合同——第2章 合同管理合同文本合同文本合同文本合同文本合同附件合同附件合同附件合同附件SOWSOW工作任务说明（工作任务说明（工作任务说明（工作任务说明（Statement of WorkStatement of Work，，，，SOWSOW））））工作分解结构（工作分解结构（工作分解结构（工作分解结构（Work Breakdown StructureWork Breakdown Structure，，，， WBSWBS））））。