ImageVerifierCode 换一换
格式:DOCX , 页数:26 ,大小:633.49KB ,
资源ID:3134184      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/3134184.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(实用的软件系统开发成本估算法软件成本管理含例子.docx)为本站会员(b****3)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

实用的软件系统开发成本估算法软件成本管理含例子.docx

1、实用的软件系统开发成本估算法软件成本管理含例子软件系统开发成本估算法功能点估算含例子一、 功能点估算法概念功能点估算法是软件项目管理众多方法中比较有技术含量的一个,也是最实用的一个。在软件项目管理中项目计划制定的优劣、合理直接关系到项目的成败,项目计划中对项目范围的估算又尤为重要。如果项目负责人对项目的规模没有一个比较客观的认识,没有对工作量、所需资 源、完工时间等因素进行估算,那么项目计划也就没有存在的意义。二、 功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。对软件项目范围的估算有很多种方法,常见的是LOC代码行和FP功能点法。它们之间的区别和

2、关系如下: 功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法,则误差会比较大。 使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。 功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算。 通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码行的。在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初 估计的不同。因此,在项目结束时还需要对项目的范围情

3、况重新进行估算,这个时候估算的结果才能最准确反映项目的规模。三、 功能点分析的步骤(含例子)本文将以国际标准IFPUG(International Function Point Users Group)组织提供的功能点估算法V4.1.1为基础进行讲解。如下图所示,首先大家应该了解功能点估算法的使用步骤。图1 功能点估算法的步骤 具体步骤包括: 1. 识别功能点的类型。 2. 识别待估算应用程序的边界和范围。 3. 计算数据类型功能点所提供的未调整的功能点数量。 4. 计算人机交互功能所提供的未调整的功能点数量。 5. 确定调整因子。 6. 计算调整后的功能点数量。三.1 识别项目的类型国际IF

4、PUG组织将软件项目分为三类,功能点估算法适用于任何一类项目: 新开发项目 二次开发的项目 功能增强的项目三.2 识别项目的范围和边界使用UML的“UseCase”用例图是以用户角度进行识别项目范围和边界的最好方法,在画用例图时就必须明确系统的边界。通过系统的边界,我们可以知道 哪些功能要计算功能点,哪些功能点是外部系统负责计算的。以图2为例:一个外贸订单系统只包含录入、修改、删除、查询和统计订单的功能,而汇率查询转换服 务是不属于该系统的。应用程序边界的识别规则大家一定要牢记,不能从技术角度去思考,必须从用户角度来定义;如果项目牵扯到多个系统,那么必须将这多个系统的边界全部描述清楚。图2 外

5、贸订单系统用例图三.3 按不同功能点计算三.3.1 功能点估算分类功能点估算法将功能点分为以下5类: 1. ILF:Internal Logical File内部逻辑文件 2. EIF: External Interface File外部接口文件 3. EI: External Input外部输入 4. EO: External Output外部输出 5. EQ: External Inquiry外部查询其中,ILF和EIF属于数据类型的功能点,EI、EO、EQ属于人机交互事务类型的功能点。 以外贸订单系统项目为例: 录入订单、修改订单、删除订单是EI; 查询订单是EO 统计订单是EQ 汇率查

6、询转换系统为EIF 订单和客户是ILF三.3.2 识别功能点的重要原则ILF、EIF要与EI、EO、EQ分开计算。对ILF和EIF复杂度的计算可以简单理解为对数据库复杂度的计算。对EI、EO、EQ复杂度的计算可以理 解为对程序开发复杂度的计算。一般软件项目都是由数据和程序构成的,因此计算ILF、EIF和计算EI、EO、EQ之间没有任何关系。三.3.3 内部逻辑文件与外部接口文件ILF内部逻辑文件内部逻辑文件是指一组以用户角度识别的、在应用程序边界内且被维护的逻辑相关数据或控制信息。ILF的主要目的是通过应用程序的一个或多个基本处理过程来维护数据。EIF外部接口文件外部接口文件是指一组在应用程序

7、边界内被查询,但在其他应用程序中被维护的、以用户角度来识别的、逻辑上相关的数据。因此,一个应用程序中的EIF必然是 其他应用程序中的ILF。EIF的主要目的是为边界内的应用程序提供一个或多个通过基础操作过程来引用的一组数据或信息。 EIF所遵循的规则: 从用户角度出发识别的一组逻辑数据。 这组数据是在应用程序外部,并被应用程序引用的。 计算功能点的这个应用程序并不维护该EIF。 这组数据是作为另一个应用程序中的ILF被维护的。ILF和EIF的复杂性计算 ILF和EIF的复杂性是取决于RET(Record element type)和DET(Data element type)的数量。DET是一

8、个以用户角度识别的、非重复的、有业务逻辑意义的字段。 DET计算的规则如下: 通过一个基本处理过程的执行,对ILF进行维护,或从ILF/EIF中返回一个特定的、用户可识别的、非重复的字段,那么每个这样的字段算一个DET。 例如:添加一个外贸订单时需要保存“订单号码、订单日期、地址、邮编”,那么对于ILF订单来说它的DET就是4个。 再如:保存订单时还会保存订单的明细。订单的明细往往作为一个子表进行保存,那么“订单号码”在主表和子表中都同时存在(主外键)。但以用户角度来识别时,存盘操作是一个最小的单位,那么订单号码只能算做一个DET。 当两个应用程序维护和/或引用相同的ILF/EIF,但是每个应

9、用程序分别维护/引用它们相应的DET时,这些DET在这两个应用程序的维护/引用中将单独计算。 例如,一个应用程序的两个“Elementary Process”基本处理过程都需要使用到“地址”的信息,地址信息又可以细分为“国家、城市、街道、邮编”。那么对于其中一个基本处理过程来说,它将整 个地址信息作为一个整体进行处理,只算一个DET;另外一个基本处理过程使用每个地址的详细信息,那么DET就是4个。 RET计算的规则如下: RET是指一个EIF/ILF中用户可以识别的DET的集合。如果把DET简单理解为字段的话,那RET就可以简单理解为数据库中的表。RET在ILF /EIF中分为两种类型:可选的

10、(Optional)和必选的(Mandatory)。计算RET的规则为以下两点: 在一个ILF/EIF中每一个可选或必选的集合都被计算为一个RET。 如果一个ILF/EIF没有子集合,则ILF/EIF被计算为一个RET。 例如:在外贸订单系统中添加一个订单时会保存“订单信息、客户的ID、部门的ID”。那么订单系统ILF中的RET为: 1. 订单信息(必选的) 2. 客户信息(必选的) 3. 部门信息(可选的) 因此ILF中RET的个数为3个。 ILF/EIF复杂度的矩阵如下:119个DET2050个DET超过51个DET1个RET低低中等25个RET低中等高6个以上RET中等高高软件项目管理中

11、的功能点估算法将功能点分为5类:ILF(Internal Logical File,内部逻辑文件)、EIF(External Interface File,外部接口文件)、EI(External Input,外部输入)、EO(External Output,外部输出)和EQ(External Inquiry,外部查询)。其中,ILF和EIF属于数据类型的功能点,EI、EO、EQ属于事务类型的功能点。EI、EO、EQ的比较 EI是处理来自应用程序边界外部的一组数据输入,它的主要目的是维护一个或多个ILF,以及/或者更改系统的行为。 EO是输送数据到应用程序边界外部的过程。它的主要目的是通过逻辑处

12、理过程向用户呈现信息。该处理过程必须包含至少一个数学公式或计算方法,或生成派生数据。一个EO也可以维护一个或多个ILF,并/或改变系统行为。 EQ是向应用程序边界外发送数据基本处理的过程。其主要目的是从ILF或EIF中通过恢复数据信息来向用户呈现。该处理逻辑不包括任何数学公式或计算方法,也不会生成任何派生数据。EQ不会维护任何一个ILF,也不会改变应用程序的系统行为。 EO和EQ的共同点是,其主要目的都是通过基本操作过程展现数据给用户。EI、EO、EQ的比较见下表。表1 EI、EO、EQ的主要目的目的EIEOEQ改变应用程序的属性或行为主要目的次要目的不允许维护一个或多个ILF主要目的次要目的

13、不允许显示信息给用户次要目的主要目的主要目的表2 EI、EO、EQ的主要行为行为EIEOEQ数学公式或计算被执行可以至少选择一次不可以至少一个ILF被修改至少选择一次至少选择一次不可以至少一个ILF或EIF被引用可选可选必选数据被重新恢复可选可选必选派生数据被创建可选至少选择一次可选应用程序的行为或属性被修改至少选择一次至少选择一次可选准备或呈现信息到系统边界外可选必选必选接受进入系统边界内的数据的能力必须可选可选三.3.4 事务类型功能点的计算规则在IFPUG的定义中有一个重要的单词“Elementary Process”基本处理过程。该过程对用户来说是一个有意义的、最小的活动单位,并且是一

14、个自包含的活动。功能点的分类,EI、EO、EQ的识别都 是基于“Elementary Process”基本处理过程的。EI的计算规则 1. 从应用边界之外收到数据。 2. 如果进入系统边界内的数据不是一个改变系统行为的控制信息,那么至少一个ILF应该被改变。 3. 对于已识别的处理过程,至少满足下面三个条件之一。 该基本处理过程的逻辑与本应用系统中其它基本处理过程的逻辑不同。该基本处理过程应该具有唯一性。例如:不能存在两个完全一模一样的存盘操作。 在应用程序边界内,该基本处理过程所使用的这组数据应该与其他基本处理过程所使用的数据不同。 在应用程序边界内,基本处理过程所引用的ILF或EIF是不同于其它基本处理过程所引用的ILF或EIF。 EO和EQ通用计算规则 必须全部满足以下内容才能被视为一个EO或EQ: 1. 从外部发送数据或控制信息到应用程序边界内。 2. 为了识别这个过程,以下三点必须满足一个: 该基本处理过程逻辑上必须是唯一的,该唯一性是指其在应用程序中与其他EO或EQ在逻辑性上保持唯一。 该基本处理过程所使用的数据应该是唯一的,该唯一性是指其在应用程序中与其他EO或EQ所使用的数据不同。 该基本处理过程所引用的ILF或EIF文件应该是唯一的,该唯一性是指其在应用程序中与其他EO或E

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1