软件工作量评估-FPA评估方法-评估模板

合集下载

软件工作量人天评估(含多种FP评估表及专家评估表)

软件工作量人天评估(含多种FP评估表及专家评估表)

大小估算 - FP简单个数一般个数复杂个数简单系数一般系数复杂系数外部输入(EI)100346外部输出(EO)010457外部查询(EQ)000346内部逻辑文件(ILF)01071015外部接口文件(EIF)00105710未调整FP个数(UFP)315100未调整FP合计:118UFP:未调整的功能点影响因数:分数 (0-5)理由分数: Data Communications(数据通信)00 = 无影响Distributed Functions(分布式数据处理)31 = 一般影响Performance(系统响应速度及处理能力)32 = 中等影响Heavily Used(大量使用)33 = 平均影响Transaction Rate(事务比率)34 = 重大影响Online Data Entry(在线数据输入)35 = 严重影响End-user Efficiency(用户友好度)3 Online Update(在线升级)0 通常请使用这里的缺省值,红色部分为重点考虑因数!Complex Processing(复杂处理)3 Reusability(复用性)3 Installation Ease(易安装性)3Operational Ease(易运行性)3 Multiple Sites(多站点支持)0 Facilitate Change(易改变性)3总分:33TDI:总的影响程度调整的FP合计:116根据公式计算:VAF = (TDI*0.01)+0.65 FP=UFP*VAFTDI:总的影响程度UFP:未调整的功能点VAF:价值调整因素FP转换成SLOC编程语言JavaSLOC/FP55(从 Capers Jones table 中找到合适的值)Total SLOC:6360软件风险:注释/前提条件:注意:1. 如果你可以用历史数据,我们建议你使用它。

例如,当你设定影响因数时,你可以参考一些历史的项目。

软件项目工作量评估方法

软件项目工作量评估方法

软件项目工作量评估方法工作量评估概述我们仔细研读了软件需求文档和设计文档,对软件功能进行了归纳和整理。

根据以往的经验,对每个功能模块所需的编码工作量进行了估算,并以此为依据,推算出整个软件生命周期的工作量。

接着,我们组织了主要项目干系人和相关专家进行工作量评审。

常见的估算方法Ad-hoc方法这种方法下的测试工作量不基于任何确定的期限。

工作一直继续直到达到一些由管理或市场人员预先定下的时间表。

或者,一直到用完了预算的经费。

这种情况普遍存在于非常不成熟的组织,并且时常有100%的错误差数。

开发时间的百分比法这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。

首先,开发工作量使用例如LOC或FP方法被估算出来,然后使用一些探索性的方法来限制测试的工作量。

通常预留项目的总花费时间的35%给测试。

5-7%给组件和集成测试,18-20%给系统测试。

10%给接收测试(或回归测试等)类比法根据以前或相似项目(主要在项目性质,领域,规模上有相似)所积累的经验或历史数据来估算工作量。

类比法估计结果的精确度取决于历史项目数据的完整性和准确度,因此,用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制,对历史项目的数据分析是可信赖的。

需要收集以下相关的历史数据:在设计和实现阶段花费的时间,测试工作的规模,例如用户需求的数量,页面数,功能点,数据样式,例如实体,字段的数量,屏幕或字段数量,测试对象的规模,例如KLOCWBS估算法将项目或产品分解为具体的工作,然后分别对各个工作进行时间估算,最终求和得出项目或产品的测试工作量/时间。

Delphi法Delphi法是最流行的专家评估技术,在没有历史数据的情况下,这种方式可以减轻估算的偏差。

Delphi法鼓励参加者就问题相互讨论。

这个技术,要求有多种相关经验人的参与,互相说服对方。

Delphi法是一种软件项目评估方法,其步骤包括:协调人向各专家提供项目规格和估计表格;召集小组会讨论与规模相关的因素;各专家匿名填写迭代表格;协调人整理出一个估计总结,以迭代表的形式返回专家;召集小组会讨论较大的估计差异;专家复查估计总结并在迭代表上提交另一个匿名估计;重复4-6,直到达到一个最低和最高估计的一致。

软件工作量评估报告

软件工作量评估报告

软件工作量评估报告一、引言二、工作量评估方法本次工作量评估采用了常用的几种方法,包括基于功能点的工作量评估法、基于模块的工作量评估法和基于经验的工作量评估法。

在评估过程中,我们对软件的需求进行了详细的分析,并与开发团队进行了多次沟通讨论,以获取更准确的数据。

三、工作量评估结果根据我们的评估,该项目的预计工作量为XXX人天。

具体的分析如下:1.基于功能点的工作量评估法:根据需求分析,我们将软件功能分为了若干个模块,并对每个模块进行了估算。

根据历史数据及开发团队的实际情况,我们给出了每个功能点的工作量估计。

通过加总,得出了整个项目的预计工作量。

2.基于模块的工作量评估法:在基于功能点的评估结果的基础上,我们将各个功能模块进行了细分,对每个模块的开发工作量进行了进一步的估计。

同时考虑到各个模块之间的依赖关系,并对开发过程中的风险进行了分析,给出了每个模块的工作量评估。

3.基于经验的工作量评估法:通过分析过往类似项目的数据,以及开发团队的技术储备和人员经验,我们得出了一个基于经验的工作量评估。

该评估方法主要考虑到了开发过程中的不确定性和风险,并给出了一定的缓冲时间。

综合以上三种方法的评估结果,我们得出了最终的工作量评估结果。

在评估过程中,我们还考虑到了开发团队的资源投入情况、开发环境的稳定性等因素,以确保评估结果的准确性。

四、结论与建议根据我们的工作量评估结果,该软件项目的预计工作量为XXX人天。

在制定项目计划和资源分配时,需要根据评估结果做出相应的调整。

针对评估结果,我们提出以下建议:1.在项目计划中充分考虑到工作量的分配,合理安排开发人员的时间,并确保开发人员的工作量符合其实际情况和能力。

2.确保项目开发过程中的需求变更控制,避免过多的变更对工作量的影响。

3.加强团队的沟通和协作,提高开发效率,减少开发过程中的沟通成本。

4.在项目计划中增加一定的缓冲时间,以应对不可预知的风险和问题。

五、总结通过对该软件开发项目的工作量评估,我们得出了一个相对准确的工作量估算结果,并提出了相应的建议。

软件开发工作量评估模板

软件开发工作量评估模板

软件开发工作量评估模板项目名称:______________________项目描述:______________________项目目标:______________________项目范围:______________________项目里程碑:______________________ 项目资源需求:______________________ 项目风险评估:______________________ 项目工作量评估:1. 需求分析阶段:- 需求收集:____小时- 需求整理:____小时- 需求确认:____小时- 需求变更管理:____小时- 需求分析总结:____小时- 小计:____小时2. 设计阶段:- 概要设计:____小时- 详细设计:____小时- 设计评审:____小时- 设计文档编写:____小时- 小计:____小时3. 编码阶段:- 编码规范制定:____小时- 编码实现:____小时- 代码评审:____小时- 代码重构:____小时- 小计:____小时4. 测试阶段:- 测试计划制定:____小时- 测试用例编写:____小时- 测试执行:____小时- 缺陷管理:____小时- 测试报告编写:____小时- 小计:____小时5. 部署与上线阶段:- 部署计划制定:____小时- 环境搭建:____小时- 数据迁移:____小时- 上线验证:____小时- 上线支持:____小时- 小计:____小时6. 维护阶段:- 问题处理:____小时/月- 功能优化:____小时/月- 版本升级:____小时/次- 小计:____小时总工作量:____小时备注:以上工作量评估仅供参考,实际工作量可能因项目实际情况而有所调整。

fpa评估

fpa评估

fpa评估FPA(功能点分析)是一种软件评估方法,用于估计软件系统的大小和复杂性。

它以功能点作为衡量标准,通过对系统的功能需求进行分类和计算,得出系统的大小,从而支持项目管理和项目估算。

以下是一个关于FPA评估的700字的总结:FPA评估是一种在软件开发生命周期中非常重要的评估方法。

它可以帮助开发团队更好地估计项目所需的工作量和时间。

评估结果能够支持项目管理和决策,使开发团队能够更好地控制项目进度和资源分配。

FPA评估方法首先要对软件需求进行分类。

它将需求分为两大类别:功能性和非功能性需求。

其中功能性需求指的是系统应该具备的功能,这些功能可以通过外部输入、外部输出、外部查询、内部逻辑文件和外部接口来衡量。

非功能性需求则指的是系统的性能、安全性、可靠性等方面的要求。

对于功能性需求的评估,FPA方法将不同的功能要求划分为不同的复杂度级别。

例如,对于外部输入需求,简单的输入可能会被评估为低复杂度,而复杂的输入则会被评估为高复杂度。

评估的依据是功能点,即每个功能要求的权重。

评估人员需要根据具体的功能要求,对每个功能点进行评估,并将这些评估结果进行加权求和,得出整个系统的功能点总数。

对于非功能性需求的评估,FPA方法可能会稍微复杂一些。

非功能性需求往往不容易直接量化和衡量,因此评估人员需要借助一些指标和模型。

例如,对于性能要求,可能需要参考系统的响应时间、吞吐量等指标,根据具体的数值范围来评估复杂度级别。

FPA评估的结果是一个关于系统大小和复杂性的指标。

开发团队可以根据这个指标来估计项目所需的工作量和时间。

同时,这个指标也可以用于项目管理和跟踪。

通过与实际的开发进展进行对比,开发团队可以更好地控制项目进度和资源分配,避免时间和成本的超支。

总而言之,FPA评估是一种非常重要的软件评估方法,可以帮助开发团队更好地估计项目的工作量和时间。

它以功能点作为衡量标准,通过对需求进行分类和评估,得出系统的大小和复杂性。

软件开发FPA功能点评估模型介绍

软件开发FPA功能点评估模型介绍

3
适用对象及特点
《应用功能点法操作规程及实施细则》适用于广东移动所有开发型 系统,包括IT支撑系统、数据业务系统软件开发规模的度量。 业务支撑系统(BSS)
如:BOSS、经分等。具有单个系统投资规模大、业务需求复杂、功能分期更新 的特点。采用功能点分析方法,便于对业务支撑系统各期业务需求的变动情况进 行对比,避免重复性功能的开发。
23
具体操作(1)
操作:
1. 分析处理过程涉及的数据文件(或实体),按下述规则识别数据功能,并将 在《系统功能清单》中做好记录(数据功能名、RET个数、RET备注)。
5、计 算调整 后功能 点数
8
目录
2
功能点方法的使用步骤
功能点计数过程 确定功能点计数类型 识别计数范围及应用系统边界 确定未调整功能点数 确定调整系数值 计算调整后的功能点数
9
确定功能点计数类型
新开发项目
•指从无到有的开发一个系 统。 •新开发项目的功能点计数 度量了项目完成时交付给 用户进行系统初次安装时 的功能。这些功能是新开 发产生的功能,不依赖于 过往项目或者应用系统。
北京邮电大学 服务科学研究所 2020/3/20
目录
1
操作规程及实施细则简介
应用背景与目的
适用对象
适用范围
编制依据
2
功能点方法的使用步骤
3
功能点计数案例实战
2
应用背景与目的
应用软件开发中的窘境
软件投资规模问题 软件投资合理性问题 开发商生产率评定 商务谈判报价的评定 需求变更与成本增加的平衡 外包开发过程的度量 需求描述不清 系统二次开发问题 维护成本问题
功能在本期不予再计数。
识别应 应用系统边界表示被计数系统和用户之间的界限以及计数系统与其他系统的界限。 3 用系统 其中,与用户的界限帮助识别事务处理功能(用USE-CASE图表示),与其他系

软件开发工作量评估方法

软件开发工作量评估方法

软件开发工作量评估方法
在软件开发过程中,工作量评估是非常重要的一项工作,它可以帮助团队更好地规划和管理项目。

以下是几种常见的软件开发工作量评估方法:
1. 基于功能点法
这种方法是通过对软件功能进行分析和描述,来评估软件开发的工作量。

它主要分为国际标准IFPUG方法和COSMIC方法。

其中IFPUG 方法是业界较为广泛使用的方法,它将软件功能分为事务性和数据性功能点,并通过不同的权重因子计算出总共的功能点数,从而确定开发工作量。

2. 基于工作分解法
这种方法是通过将整个软件开发过程分解为多个子过程,然后对每个子过程进行评估。

例如,将软件开发过程分解为需求分析、设计、编码、测试等子过程,然后对每个子过程进行工作量评估。

这种方法的优点在于可以更加详细地描述每个子过程的工作量,但工作量评估的准确度也取决于对每个子过程的分解和评估的质量。

3. 基于历史数据法
这种方法是通过对类似的历史项目的工作量进行分析和比较,来评估当前项目的工作量。

例如,可以通过查看以前的项目中各个阶段的工
作量,并结合当前项目的特点,来确定当前项目需要的工作量。

这种方法的优点在于可以比较准确地预估工作量,但需要有大量的历史数据作为支持。

以上是软件开发过程中常见的几种工作量评估方法,每种方法都有其独特的优点和适用场景,选择合适的方法可以帮助团队更好地规划和管理项目。

fpa标准功能点估算

fpa标准功能点估算

FPA(功能点分析)是一种用来度量软件系统规模的方法,它从用户视角来度量产品规模,不注重产品的内部结构和技术复杂度。

FPA估算模型中,任何一个软件系统都被看作是由五种要素组成,分别是:外部输入处理(EI)、外部查询处理(EQ)、外部输出处理(EO)、内部逻辑文件(ILF)和外部参照文件(ER)。

通过估算系统中这五种要素的个数,并乘以适当的权值(权值即为每个要素的功能点数)就可以计算出系统的功能点数,进而估算出系统的规模。

在FPA中,功能点数可以通过以下步骤来估算:
1.确定系统中的功能区域:首先根据系统的主要功能,将系统划分为若干个功能
区域。

每个功能区域对应一个或多个功能。

2.确定功能区域的规模:每个功能区域的规模可以根据其涉及的数据量、处理的
数据复杂度、用户数量等因素来确定。

3.计算功能区域的功能点数:根据每个功能区域的规模和复杂度,计算出每个功
能区域的功能点数。

4.确定功能区域的权重因子:根据每个功能区域的重要性和复杂度,确定每个功
能区域的权重因子。

5.计算总的功能点数:将每个功能区域的功能点数乘以对应的权重因子,然后将
这些结果相加,就可以得到总的功能点数。

FPA标准是国际功能点用户组(IFPUG)维护和推动的,它不定期发布Counting Practices Manual来统一不同公司和产品的功能点计算模型。

这个模型基于大量已完成项目的分析数据,非常全面和精确。

对于同一个产品,不同的公司,不同的人参照CPM计算出来的功能点数应当是一样的。

软件系统工作量评估模板

软件系统工作量评估模板

2
2
4
《需求调研提纲》
1
《CR1434开发计划及实施时间表》
1
1
2
《功能规格说明书》
1
1
2
《系统开发概要设计》
5
3
5
6
3
《系统开发详细设计》
7
7
10
14
5
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Hale Waihona Puke 1111
1
1
1
1
1
1
1
1
1
6
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
26
PJHG_FGB_20110701.csv
市场与操作风险管理 部
新建数据库表
生成报表数据
1
1
页面新建菜单、报表展现、另存Excel文件
27
PJHG_FGB_20110701_BCC.csv
市场与操作风险管理 部
新建数据库表
生成报表数据
1
1
页面新建菜单、报表展现、另存Excel文件
28
PJSGZ_FGB_20110701.csv
页面新建菜单、报表展现、另存Excel文件

FPA功能点估算法实例

FPA功能点估算法实例

FPA功能点估算法实例FPA(Function Point Analysis)功能点估算法是一种软件估算方法,用于估计软件的功能规模。

它通过对软件功能进行分类和计数,然后根据不同的功能类型和难易程度来估算软件的开发和维护工作量。

下面是一个FPA功能点估算法的实例,以便更好地理解该方法的应用。

假设我们要估算一个电子商务网站的开发工作量。

首先,我们需要确定该网站的各个功能模块,例如用户管理、商品管理、订单管理、支付管理等。

然后,根据FPA的分类标准,我们将这些功能模块分为以下几个类别:1.输入(ILF):用户管理、商品管理、订单管理等需要输入数据的功能模块。

2.输出(EIF):根据输入数据生成的报表、邮件通知等输出功能。

3.查询(EQ):根据用户的查询条件检索相关信息的功能。

4.内部逻辑文件(ILF):存储和维护数据的功能模块,例如用户信息、商品信息、订单信息等。

5.外部接口文件(EIF):与外部系统交互的功能模块,例如与支付系统的对接。

接下来,我们需要为每个功能模块计算功能点数。

根据FPA的计算方法,不同类型的功能有不同的权重。

以输入功能模块为例,我们可以使用以下权重:-简单:3个功能点-中等:4个功能点-复杂:6个功能点假设用户管理模块是中等复杂度的输入功能模块,商品管理模块是简单的输入功能模块,订单管理模块是复杂的输入功能模块。

计算得到的功能点数如下:用户管理模块:4个功能点商品管理模块:3个功能点订单管理模块:6个功能点同样地,我们可以为输出、查询、内部逻辑文件和外部接口文件等功能模块进行功能点数的计算。

在得到所有功能点数后,我们可以使用FPA功能点估算法的公式来计算软件的总功能点数。

FP=ILF+EIF+EQ+ILF+EIFILF表示内部逻辑文件的功能点数,EIF表示外部接口文件的功能点数,EQ表示查询的功能点数。

根据上述例子的计算结果,我们可以得到最终的功能点数:FP=3+1+0+3+1=8个功能点最后,我们可以根据功能点数来进行工作量估算。

开发工作量评估模板

开发工作量评估模板

开发工作量评估模板
在软件开发项目中,对工作量进行准确评估是非常重要的。


发工作量评估模板是一种用于帮助团队成员评估项目工作量的工具。

它可以帮助团队成员更好地理解项目的复杂性和需要投入的时间,
从而更好地规划和管理项目进度。

一个典型的开发工作量评估模板包括以下几个方面:
1. 任务描述,列出需要完成的具体任务或功能模块。

2. 预估工作量,对每个任务或功能模块进行工作量估算,通常
以小时或天为单位。

3. 负责人,指定负责完成每个任务或功能模块的团队成员。

4. 优先级,确定任务或功能模块的优先级,以便在资源有限的
情况下进行合理分配。

5. 完成日期,设定每个任务或功能模块的预期完成日期。

开发工作量评估模板的使用可以帮助团队成员更好地了解项目
的需求和复杂性,从而更好地规划和分配工作。

同时,它也可以帮
助项目经理或团队领导更好地监控项目进度,及时发现和解决问题。

在实际使用开发工作量评估模板时,团队成员应该尽可能准确
地估算工作量,同时也要考虑到可能出现的风险和不确定性因素。

此外,评估模板也应该根据项目的实际情况进行调整和优化,以确
保其有效性和实用性。

总之,开发工作量评估模板是软件开发项目管理中的重要工具,它可以帮助团队更好地规划和管理项目工作,提高项目的成功率和
质量。

软件开发FPA功能点评估模型介绍

软件开发FPA功能点评估模型介绍

□ 本期需求说明书,名称: □ 其他文档,文档1:
文档2:
与用户(人)的边界: 需求说明书中:2.2角色定义的USER-CASE图 与其他系统的边界关系: 需求说明书中:2.3系统边界图
(其他需要 的信息)
目录
2
功能点方法的使用步骤
功能点计数过程
确定功能点计数类型
识别计数范围及应用系统边界
确定未调整功能点数

•提供一个已安装应用系统的基本的功能点数;
•提供一个功能点数从而能比较两个不同供应商所交付的程序包的功能。
•新开发项目的计数范围即对应应用系统的软件需求规格说明书(和概要设计);
2
识别计 数范围
•二次开发项目的计数范围除了软件需求规格说明书(和概要设计)之外,还包括计 数应用系统以往相关项目的功能需求说明书(和概要设计) 。通过分析以往项目 的功能需求说明书,查看本期需求说明书中是否存在以往已开发的功能,该类
功能在本期不予再计数。
识别应 应用系统边界表示被计数系统和用户之间的界限以及计数系统与其他系统的界限。 3 用系统 其中,与用户的界限帮助识别事务处理功能(用USE-CASE图表示),与其他系
边界 统的界限帮助识别数据功能(接口图表示)。
4
记录系 记录内容包括: 1)计数目的; 2)计数范围; 3)应用系统边界; 4)任何与 统特征 以上相关的假设
数据/模块 XX模块
处理过程/数据文件 XX过程 …..
17
具体操作
操作:
阅读需求说明书,寻找发生在应用系统中的用户活动(物理输入或事务处理文件 或显示屏),根据识别规则判定该活动是否为基本事务处理过程。
识别规则: 下面所有的计数规则必须都满足才能被识别为一个基本事务处理过程: 1. 该过程是对用户有意义的最小的(不可再分的)活动单元; 2. 该过程应与应用系统的业务保持一致,即执行该过程能确保对应业 务的完整完成。

3种常见软件项目工作量评估方法简述

3种常见软件项目工作量评估方法简述

3种常见软件项⽬⼯作量评估⽅法简述前⾔本⽂的⽬标读者是从事软件⾏业想快速了解软件开发过程⼯作量评估的⼈员。

很多,如代码⾏法、类⽐法、WBS、故事点、⽤例点、NESMA、FPA、cosmic、COCOMOⅡ等。

本⽂只是选取主流评估⽅法进⾏简述,每⼀种⽅法在实际操作过程中有若⼲条计数规则,在此并未阐述,并不能作为评估⼯作的实施指南。

实际使⽤⽅法时,需以各⽅法发布机构发布的官⽅⽂档为准。

⼀、 功能点 FPA ⽅法(⼀) 简介FPA 是从⽤户⾓度出发度量软件规模的⼀种⽅法。

它从⽤户的⾓度出发,将系统分为数据功能和事物功能两⼤类,分别根据具体的规则来计算功能点,最后结合系统的特征因⼦来调整功能点数, 从⽽得到最终的系统规模。

FPA 较适⽤于商业数据处理、管理信息系统的估算,因为它能更好地反映系统需求上的复杂度和数量。

从满⾜客户需求的⾓度讲,FPA 具有阶段性,对⽤户早期参与项⽬管理、项⽬经理制定项⽬计划更有意义。

(⼆) 重要概念是从⽤户视⾓出发,对软件的规模从逻辑设计的⾓度进⾏度量的标准⽅法。

在功能点估算的过程中,以下概念应贯穿始终:1、 ⽤户视⾓⽤户视⾓(User View)是指功能点被⽤户所认可,由⽤户需求书⾯正式描述,且独⽴于所采⽤的开发技术。

2、 穿越系统边界穿越系统边界(Application Boundary)是指数据或控制信息由系统内发送到系统外,或由系统外发送到系统内。

是否穿越系统边界是 FPA 重要的判断标准。

3、 IPO 的异同输⼊(Input)、处理过程(Process)和输出(Output)的同与不同亦是FPA 重要的判断标准。

(三) FPA 估算⽅法基本步骤1、 收集可得的⽂档⽂档可以包括需求、数据/对象模型、类图、数据流图、⽤例、过程描述、报表显⽰、界⾯显⽰、⽤户⼿册,以及其它软件开发⽂档。

2、 确定计数范围和边界并识别功能⽤户需求计数范围和边界需识别计数⽬的。

不同的计数⽬的决定了计数范围和软件边界的划分。

软件开发FPA功能点评估模型介绍

软件开发FPA功能点评估模型介绍

3
适用对象及特点
《应用功能点法操作规程及实施细则》适用于广东移动所有开发型 系统,包括IT支撑系统、数据业务系统软件开发规模的度量。 业务支撑系统(BSS)
如:BOSS、经分等。具有单个系统投资规模大、业务需求复杂、功能分期更新 的特点。采用功能点分析方法,便于对业务支撑系统各期业务需求的变动情况进 行对比,避免重复性功能的开发。
功能在本期不予再计数。
识别应 应用系统边界表示被计数系统和用户之间的界限以及计数系统与其他系统的界限。 3 用系统 其中,与用户的界限帮助识别事务处理功能(用USE-CASE图表示),与其他系
边界 统的界限帮助识别数据功能(接口图表示)。
4
记录系 记录内容包括: 1)计数目的; 2)计数范围; 3)应用系统边界; 4)任何与 统特征 以上相关的假设
数据业务应用软件
全业务时代,数据业务应用软件越来越丰富。
4
适用范围
本规程涉及的部门以及各部门职责如下: 规划技术部、设计院
在计划阶段,根据软件需求规格说明书及本操作规程,估算应用系统的功能点数, 确定应用软件的投资规模; 项目完成后,根据系统设计文档及本操作规程,重新测算应用系统的功能点数,确 定实际开发的应用系统规模,为项目后评估提供依据。
系统开发商
按照软件需求规格说明书模板、软件概要设计模板编写需求规格说明书和概要设计。 按照规程计数软件开发的功能点,并采用功能点报价方式。
5
编制依据与改进创新
本规程的编制主要依据: IFPUG发布的功能点计数实践手册4.2版;The International Function Point Users Group. Function Point Counting Practices Manual (Release 4.2).2004 《中国移动广东公司应用软件功能点法操作规程及实施细则委 托合同》
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

1) 数据是从系统边界外部获取的 EI (External Input) 获得数据的过程,对终端用户 2) 事务处理是对ILF的插入、修改、 数据维护 的输入进行相关的处理 删除操作
2
3
1) 向系统边界的外部输出数据 2) 一般可以包含下列业务处理逻辑: 一个以上的数学运算处理 EO(External Output) 反馈数据的过程,完成对票据 由基础数据生成新的数据 数据编辑 、报表等的输出 对一个以上的ILF进行插入、修改、 三种处理EI、EQ、EO的复杂程度通常是用该处理中使用 文件个数(通常对应为数据库表数)以及用到的文件中 删除操作 的项目数(通常对应为数据库表的字段数)来度量的, 执行系统动作的变更 复杂程度与文件数和项目数成正比。即用到的文件数约 多,项目数越多,复杂程度就越高 1) 从系统边界外部获取数据 2) 向系统边界外部输出数据 3) 如果包含下列处理逻辑,则不是 EQ(External EQ: 针对终端用户的查询请求,输 Inquiry) 一个以上的数学运算处理 出相应的检索结果 数据展现。 由基础数据生成新的数据 对一个以上的ILF进行插入、修改、 删除操作 执行系统动作的变更 ILF (Internal Logical File) 类表 是在信息系统内部,为了完成 文件ILF、EIF的复杂程度通常是用该文件的纪录种类数 相关功能使用的逻辑文件,包 在计测系统范围内,有检索操作,同 和项目数来度量的,记录种类越多,项目数越多,复杂 括顺序文件、数据库表、临时 时也有插入、更新、删除操作的数据 程度就越高 文件等 1) 在计测范围内的系统检索,在计测 范围外的系统保存的数据 文件ILF、EIF的复杂程度通常是用该文件的纪录种类数 该系统和外部其他信息系统为 2) 在计测系统范围内,没有插入、更 和项目数来度量的,记录种类越多,项目数越多,复杂 了交换数据而使用的接口文件 新、删除等操作的数据 程度就越高 3) 是计测范围外系统的ILF
2012-10-25
华为机密,未经许可不得扩散
第1页,共1页
二、填写模板
序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 …… XX模块 XX模块 数据提取ETL 数据交互ETL 产品资费分析模块 问题分析模块 关键业务指标分析模块 产品体系结构分析模块 XX模块 XX模块 XX模块 XX模块 系统 模块 功能 类型 EI EQ EI EQ EQ EQ EQ EQ EQ EO EO EO EQ EI EI EI EQ EQ EQ EQ EQ EIF EIF EO EO EO EO ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF XX管理系统 ILF ILF ILF ILF ILF ILF ILF ILF 内部逻辑文件 ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF ILF EIF EIF EIF EIF 外部接口文件 EIF EIF EIF EIF EIF EIF 复杂度 高 高 高 中 中 高 中 中 中 中 高 高 高 中 中 中 中 中 低 低 低 高 高 高 高 高 高 高 低 低 中 低 低 低 低 低 低 低 低 低 高 低 中 低 低 中 低 高 低 低 低 低 中 高 低 高 低 低 低 低 低 低 高 高 中 高 中 高 中 高 高 高 中 高 高 高 低 高 高 高 低 中 中 高 高 高 高 高 高 备注
超级邮箱应用软件功能点调查表(0422)
内部公开
一个软件都被看作是由外部输入处理、外部输出处理、外部查询处理、内部逻辑文件和外部参照文件五种要素组成。
一、填写项目说明ห้องสมุดไป่ตู้
序号 1 项目 说明 判定标准 复杂度判断标准
EI的复杂度
文件数 0-1 项目数 1-4 5-15 >15 低 低 中 低 中 高 中 高 高 2 >2
EO、EQ的复杂度
文件数 0-1 项目数 1-5 6-19 > 19 低 低 中 低 中 高 中 高 高 2-3 >3
4
ILF、EIF的复杂程度
纪录种类 1 项目数 1-19 20-50 >50 低 低 中 低 中 高 中 高 高 2-5 >5
5
EIF (External Interface File) 接口类表
相关文档
最新文档