规模估算.docx
- 文档编号:17202010
- 上传时间:2023-04-24
- 格式:DOCX
- 页数:20
- 大小:24.24KB
规模估算.docx
《规模估算.docx》由会员分享,可在线阅读,更多相关《规模估算.docx(20页珍藏版)》请在冰豆网上搜索。
规模估算
项目规模估算
下面所述是进行项目大小估算时使用的功能点估算方法,其实估算项目大小的方法有很多。
此方法是在项目初期,项目缺少历史参考数据和项目人员缺乏相应的行业经验时一个比较好的估算方法。
有人询问项目估算的意义
1.首先可以让项目大小有一个理性的认识,估算出的项目大小能够让整个项目团队明确项目进程中的工作重点和难点,有利于团队分工的展开
2.在估算功能点的过程中可以重新梳理项目思路,对于更细致理解项目需求有所帮助
3.在项目初期,特别是在投标的时候用来基本判断项目的工作量大小和成本估算有参考性价值
估算方法有很多,这里选其一给大家展开介绍,如果大家有兴趣,接下来的时间会再给大家介绍其他的项目估算方法。
在项目前期初步进行估算的时候,从需求出发的功能点估算往往比直接进行代码估算功能容易,而且可以使用功能点作为基点,粗略的计算出以代码行表示的规模度量值。
功能点估算有很多不同的方法,大家可以在www.ifpug.org国际功能点用户组网站找到相应标准。
下面是步骤
I】确定系统模块五大基础部件类型(关于此点,如需了解更详细资料请参阅
企业信息系统主要的功能是按企业的业务流程处理和数据有关的业务逻辑,所以功能点一般分为这么几块:
1.外部输入(EI):
以登陆为例在登陆时输入的用户名和密码就是一个外部输入
2.外部输出(EO):
程序最终供用户或其它程序设备使用的输出信息
3.外部查询(EQ):
输入/输出组合,其中一个输入引出的一个即使的简单输出。
其和外部输出的区别在于,查询直接从数据源中检索格式化好的数据,而输出需要处理,组合调配不同格式信息。
另外,内部逻辑文件与外部接口文件
4.ILF内部逻辑文件
内部逻辑文件是指一组以用户角度识别的,在应用程序边界内且被维护的逻辑相关数据或控制信息。
ILF的主要目的是通过应用程序的一个或多个基本处理过程来维护数据。
(也可以理解成一个标准化的配置文件XML和此配置文件相关实现方法和类)
5.EIF外部接口文件
外部接口文件是指一组在应用程序边界内被查询,但它是在其他应用程序中被维护的,以用户角度来识别的,逻辑上相关的数据。
EIF的主要目的是为边界内的应用程序提供一个或多个通过基础操作过程来引用的一组数据或信息。
(系统对外提供信息源的标准化信息载体文件(xml)和与此相关的提供外部接口或通过外部接口实现系统内功能的类)
II】估算各类型中的功能基础元素的个数
接下来决定系统模块或功能点的复杂程度,(这里更正一下昨天在会议时给大家传递信息时的不准确的地方,请大家注意看评估复杂度的时候的依赖条件,是由一个标准矩阵列表来决定,而计算出的结果是原始功能计数点而不是LOC,LOC由功能点和编程语言语句表转化因子表乘积实现)
1.首先是DET数据元素类型,可以看做是实现业务的字段数
2.另外是RET记录元素类型,可以看做是业务关键点的基础类的个数
3.FTR,是被一个事物操作读取或维护的一个ILF,或者是被一个事物操作读取的一个EIF
III】根据公式计算功能个数复杂度,确定复杂度
FTR和EI,EO,EQ组合计算出EI,EO,EQ功能方向的复杂度(表一,表二)
RET和DET组合计算ILF/EIF功能点方向的复杂度(表三)
表一:
EI复杂度计算矩阵
1~4个DET
5~15个DET
多于16个DET
0~1个FTR
低
低
中等
2个FTR
低
中等
高
大于2个FRT
中等
高
高
表二:
EO和EQ复杂度计算矩阵
1~5个DET
6~19个DET
多于20个DET
0~1个FTR
低
低
中等
2~3个FTR
低
中等
高
多于4个FTR
中等
高
高
表三:
ILF/EIF复杂度的矩阵如下
1~19个DET
20~50个DET
超过51个DET
1个RET
低
低
中等
2~5个RET
低
中等
高
6个以上RET
中等
高
高
IV】接下来根据复杂度和原始功能点技术值使用乘数计算功能点数(表四)
表四:
计算原始功能点结果(*号后面是功能点乘数,来自行业数据)
功能点
程序特性 简单 一般 复杂
外部输入 0*3 1*4 2*6
外部输出 7*4 0*5 1*7
外部查询 20*3 0*4 0*6
外部文件 2*5 1*7 0*10
内部文件 0*7 0*10 1*15
合计 98 11 34
UFC 143
V】根据调整因子调整原始功能点个数(在我们此次毕业设计项目中酌情使用,第五部分范例转自
计算调整因子
功能点的调整系数是通过通用系统特性及其影响程度来评定的,对每个常规系统特性的评估由其影响程度(DI)而定,分为0-5级:
0 毫无影响1 偶然影响2 适度影响3 一般影响4 重要影响5 强烈影响 然后依次对以下14个系统常规特性进行打分,并带入以下计算公式算出功能点的调整因子。
ValueAdjustmentFactor=(sumof(DI)*0.01)+0.65
1数据通讯
数据通讯指的是应用程序直接与处理器通讯的程度。
通常我们都是通过某种通讯手段来实现在一个应用中所使用的数据或者控制信息的。
连接到本地控制器上的终端被认为是使用通讯设施,而协议指的是两个系统或者两个设备之间进行通讯时所使用的一种约定。
所有的数据通讯链接都需要某种协议。
0
应用程序是单纯的批处理或者PCstand-alone
1
应用程序是一种批处理过程,但是包含远程数据的录入或远程打印
2
应用程序是一种批处理过程,但是包含远程数据的录入和远程打印
3
应用程序包括在线数据收集或者包括批处理或查询系统的远程处理的前端应用
4
应用程序不单只是前端应用,但是仅支持一种远程处理通讯协议
5
应用程序不单只是前端应用,还支持多于一种的远程处理通讯协议
2分布式数据处理
分布式数据处理是应用在内部组件之间传递信息的程度。
这个特性是在应用边界内体现的。
0
应用程序不支持组件之间的数据传输和处理功能
1
应用程序为用户可能进行的处理准备数据(例如使用电子表格或者数据库等)
2
应用程序所准备的数据是为了在系统另外一个组件上传输和处理。
并非为终端用户所处理。
3
分布式处理和数据传输是在线的,并且是单向的
4
分布式处理和数据传输是在线的,并且是双向的
5
由系统中最恰当的组件动态地执行处理功能
3性能
性能是吞吐量、处理时间等指标对开发的影响。
用户所提出的性能要求将直接影响到系统的设计,实施,安装和支持。
0
用户没有提出性能方面的要求
1
用户提出了性能和设计方面的要求,但不需要采取特定措施
2
响应时间和吞吐量在系统峰值时是关键的,但是不需要采取相应的CPU 使用方面的特殊设计。
处理的最后期限是在下一个工作日。
3
在任何时候响应时间和吞吐量都是关键的,但是不需要采取相应的CPU 使用方面的特殊设计。
处理的完成期限比较严格
4
除了上面一项的要求外,由于对需求的要求比较严格,在设计阶段就要进行性能分析
5
除了上面一项的要求之外,在设计和实施阶段需要使用性能分析工具来判断性能要求的完成情况
4大业务量配置
大业务量配置指的是计算机的资源对应用开发的影响程度。
大业务量的运行配置对设计有特殊要求,是必须考虑的一个系统特性。
0
没有提出明确的运行方面的限制
1
有运行方面的限制,但是不需要采取特别的措施以满足运行限制
2
提出了一些安全和时间方面的限制
3
应用程序的某些部分对处理器有特定的要求。
4
提出的运行限制对应用的中央处理器或者专用处理器有特殊的要求
5
除上面一项之外,还对应用的分布式组件提出了限制
5事务处理率
事务处理率是业务交易处理速度的要求对系统的设计,实施,安装和支持等的影响。
0
预计不会出现周期性的高峰事务处理期
1
预计会有周期性的高峰事务处理期(例如:
每月、每季、每年)
2
预计每周都会出现高峰事务处理期
3
预计每天都会出现高峰事务处理期
4
用户在应用程序需求或者服务级别协议中对事务率要求很高,因此必须在设计阶段进行性能分析。
5
用户在应用程序需求或者服务级别协议中对事务率要求很高,因此必须进行性能分析并在设计、开发和安装阶段中使用到性能分析工具。
6在线数据输入
在线数据输入是指数据通过交互的方式输入系统程度。
系统中包括在线数据输入和控制信息功能。
0
所有事务都是批处理的。
1
1%~7%的事务是以交互式的方式进行数据录入
2
8%~15%的事务是以交互式的方式进行数据录入
3
16%~23%的事务是以交互式的方式进行数据录入
4
24%~30%的事务是以交互式的方式进行数据录入
5
30%以上的事务是以交互式的方式进行数据录入
7最终用户效率
最终用户效率是指对应用的人文因素以及使用的便捷方面的考虑程度。
如下功能设计是针对最终用户效率的:
Ø 页面导航
Ø 菜单
Ø 在线帮助或文档
Ø 光标自动跳转
Ø 可以滚动
Ø 在线远程打印
Ø 预定义的功能键
Ø 在线做批量提交任务
Ø 光标可以选取界面上的数据
Ø 用户使用大量反白显示、重点显示、下划线或其他的标识
Ø 在线copy用户文档
Ø 鼠标拖动功能
Ø 弹出窗体
Ø 使用最少的界面完成某种商业功能
Ø 双语言支持(如果选择了这个就算4项)
Ø 多语言支持(如果选择了这个就算6项)
0
以上的一个都不包括
1
包括以上的1~3个
2
包括以上的4~5个
3
包括以上的6个或以上,但是没有用户对于效率的要求
4
包括以上的6个或以上,对用户使用效率有较高要求,因而必须考虑用户方面的设计(例如,最少击键次数、尽可能提供默认值、模版的使用)
5
包括以上的6个或以上,用户对效率的要求使得开发人员必须使用特定的工具和流程以判定用户对效率的要求已经被达成
8在线更新
在线更新是指内部逻辑文件ILF 被在线更新的程度。
应用系统提供在线更新内部逻辑文件的功能。
0
没有在线更新
1
包含1~3 个控制文件的在线更新。
更新的流量低,恢复容易
2
包含对4 个以上控制文件的在线更新。
更新的流量低,恢复容易
3
包含对主要ILF 的更新
4
除了3 之外,在设计和实施中要考虑对数据丢失的防范。
5
除了4 之外,大量的数据恢复工作要考虑成本因素,同时包含了高度自动化的恢复流程。
9复杂处理
复杂处理描述了逻辑处理对应用开发的影响程度。
它包含以下要素:
Ø 敏感控制(例如特殊的审核过程)和/或程序特定的安全处理
Ø 大量的逻辑处理
Ø 大量的数学处理
Ø 因为例外处理造成的需要重新处理的情况(例如,由TP中断、数据值缺少和验证失败导致的ATM事务)
Ø 多种可能的输入/输出造成的复杂处理
0
上面一个都不满足
1
只满足一个
2
只满足两个
3
满足三个
4
满足四个
5
都满足
10可复用性
应用系统中的应用和代码经过特殊设计、开发和支持,可以在其他应用系统中复用。
0
没有可复用的代码
1
代码在应用之内复用
2
应用中被其他用户复用的部分不足10%
3
应用中被不止一个用户使用的部分超过10%
4
应用遵从一种易于复用的方式被打包和文档化。
用户在源代码级客户化该应用
5
应用按照一种易于复用的方式被打包和文档化。
用户使用用户参数来对该应用进行客户化
11.易安装性
易安装性指应用系统的转换和安装容易度对开发的影响程度。
系统测试阶段提供了转换和安装计划和/或转换工具。
0
用户对安装没有特定的要求
1
用户对安装没有特定的要求,但有特定的安装环境要求
2
用户提出了安装和转化的要求,转化/安装指南被经过测试提供给用户。
但是转化的影响对该应用不重要
3
用户提出了安装和转化的要求,转化/安装指南被经过测试提供给用户。
转化的影响对该应用来说是重要的
4
除了2 的要求之外,需要提供经过测试的自动化的安装和转化工具。
5
除了3 的要求之外,需要提供经过测试的自动化的安装和转化工具。
12.易操作性
易操作性指的是应用对运行的影响程度,如有效启动、备份和恢复规程的影响。
易操作性是应用提供的一种特性,它最小化了手工操作的要求。
0
用户没有指定除正常备份程序外的其它特定操作
1
提供高效的启动、备份和恢复进程,但需要人手操作
2
提供高效的启动、备份和恢复进程,不需要人手操作(当作两项计算)
3
应用程序对磁带的需求最小化
4
应用程序对硬拷贝处理的需求最小化
5
程序设计成无人操作模式。
无人操作模式的意思是除了启动和关闭之外,不需要对系统进行操作。
程序的其中一个功能就是错误自动恢复。
13.多场地
多场地指应用系统经特殊设计、开发可以在多个组织、多个地点应用的程度。
0
用户需求不含多场地和组织的要求
1
考虑了多场地的要求,但是设计要求应用在不同的场地使用相同的软硬件环境
2
考虑了多场地的要求,但是设计要求应用在不同的场地使用类似的软硬件环境
3
考虑了多场地的要求,同时设计支持应用在不同的场地使用不同的软硬件环境
4
在1 或者2 的要求之上,提供了经过测试的多场地的文档和支持计划
5
在3 的要求之上,提供了经过测试的多场地的文档和支持计划
14.支持变更
支持变更指的是应用在设计上考虑支持处理逻辑和数据结构变化的程度。
可以具有如下的特性:
Ø 提供可以处理简单要求的弹性查询和报告功能,如对一个ILF进行与(或)逻辑
Ø 提供可以处理一般复杂度要求的弹性查询和报告功能,如对多于一个的ILF进行的与(或)逻辑(当作两项计算)
Ø 提供可以处理复杂要求的弹性查询和报告功能,如对一个或多个ILF进行的与(或)逻辑的组合(当作三项计算)
Ø 业务控制数据被保存到用户通过在线交互进程维护的表中,但变更只会在第二个工作日生效
Ø 业务控制数据被保存到用户通过在线交互进程维护的表中,且变更即时生效
0
一个都不满足
1
合计满足一个
2
合计满足二个
3
合计满足三个
4
合计满足四个
5
合计满足五个
计算调整后的功能点个数
国际的IFPUG组织将软件项目分为三类,功能点估算法适用于任何一类项目,其计算公式中的术语请详见表1。
● 功能点的原始计算公式:
FPCount=UFP*VAF
● 新开发项目有时新开发的软件项目也需要与其他现存的软件系统进行整合,例如:
一个企业新开发的MIS内部管理系统经常会与财务系统进行整合。
这个时候除了考虑本身项目的功能点个数外,还要考虑系统整合或数据迁移部分的工作量,因此其功能点计算公式如下:
FPCount=(UFP+CFP)*VAF
● 二次开发的项目有时新开发的软件项目是在原有基础上进行二次开发的,只是为了增加一些新的功能,因此其功能点计算公式如下:
FPCount=ADD*VAF
● 功能增强的项目对于功能增强的项目功能点估算比较复杂,在功能点增强前大家需要计算有哪些是新增加的功能,有哪些是被修改的功能,还有哪些是属于数据迁移或系统整合的功能。
然后计算新系统技术复杂度的调整因子“VAFA”,并在此基础上计算系统功能点的数量。
当然此类项目也会去掉一些原有功能,那么在原有系统的技术复杂度基础上重新计算功能点的调整因子“VAFB”,再计算所去掉功能贡献的功能点数量,因此其功能点计算公式如下:
FPCount=[(ADD+CHGA+CFP)*VAFA]+(DEL*VAFB) 表1 功能点技术公式术语
术语
英文
中文含义
ADD
Addedfunctionality
被添加的功能点个数
CFP
Conversionfunctionality
被转换的功能点个数
CHGA
UFPofchangedfunctionalityafterenhancement
功能增强后所改动的功能所贡献的未调整的功能点个数
DEL
Deletedfunctionality
被删除的功能点个数
UFP
Unadjustedfunctionalpointcount
未调整的功能点个数
VAF
ValueadjustmentfactorVAF=(sumof(DI)*0.01)+0.65
功能点的调整因子的计算公式VAF=(sumof(DI)*0.01)+0.65
VAFA
Valueadjustmentfactorafterenhancement
功能增强后的功能点调整因子
VAFB
Valueadjustmentfactorbeforeenhancement
功能增强前的功能点调整因子
范例
以员工管理系统为范例,在添加一个员工资料时会使用到员工的一般信息、员工的教育情况、工作经历和家属信息。
员工又会隶属于某个部门,在本系统中会有一个对部门进行维护的功能。
员工的工资是由另外一个财务系统提供的。
因此其用例图如下所示:
图员工管理系统用例图
Ø 假设员工基本信息如下所示:
员工ID(标签控件)
员工名称
性别
生日
婚否
所属部门ID(标签控件)
所属部门名称
——受教育的时间
——学校名称
——所学专业
——工作时间
——工作单位
——工作部门
——工作职务
——亲属的姓名
——之间关系
——亲属年龄
——工作单位
Ø 假设部门信息如下所示:
部门ID(标签控件)
部门名称
Ø 假设工资表信息如下所示:
员工ID(标签控件)
员工姓名
金额
单位
本范例识别出来ILF和EIF功能点个数如下表所示。
ILF内部逻辑文件
RET
DET个数
复杂度
未调整的FP个数
员工信息
员工基本信息、员工受教育情况、工作经历、亲属信息,共4个。
18个
低
7
部门信息
部门基本信息,共1个。
2个
低
7
EIF外部接口文件
RET
DET个数
复杂度
未调整的FP个数
工资表
员工基本信息、工资信息,共2个。
4个
低
5
合计:
19个
本范例识别出来EI、EQ和EO功能点个数如下表所示。
EI
FTR
DET个数
复杂度
未调整的FP个数
添加员工信息
员工、部门、工资表
员工信息的两个标签控件的内容不是用户输入的,因此不算。
共16个。
部门信息与员工信息中的部门字段重复,因此一个都不算。
工资表中的员工ID和名称不能重复,因此只能算金额和单位,所以共2个18个
高
6
修改员工信息
员工、部门、工资表
18个同上
高
6
删除员工信息
员工、部门、工资表
1个员工ID
中等
4
添加部门信息
部门
1个一个标签控件的内容不是用户输入的,因此不算
低
3
修改部门信息
部门
1个一个标签控件的内容不是用户输入的,因此不算
低
3
删除部门信息
部门
1个部门ID
低
3
合计:
25个
EQ
FTR
DET个数
复杂度
未调整的FP个数
查询员工信息
员工、部门、工资表
20个
高
6
查询部门信息
部门
2个
低
3
合计:
9个
EO
FTR
DET个数
复杂度
未调整的FP个数
统计员工年薪
员工、工资表
员工ID、员工名称年份、年薪、单位共5个
低
4
本系统的通用系统特性及其影响程度如下表所示:
系统特性
分数
数据通讯
3
分布式数据处理
2
性能
0
高强度配置
0
交易速度
0
在线数据输入
5
最终用户效率
2
在线更新
3
复杂的处理
0
可复用性
3
易安装性
0
易操作性
0
多场地
0
支持变更
1
合计:
19
调整因子 = 19*0.01 +0.65 = 0.84
最终调整后的功能点数量为:
(19+25+9+5)*0.84=48.72个
VI】如果需要把功能点转换成代码行,可以使用每功能点对应编程语言语句数转换表
每功能点对应编程语言语句数
语言 最小值 中等 最大值
C 60 128 170
C# 40 55 80
C++ 40 55 140
Java 40 55 80
Perl 10 20 30
SQL 7 13 15
VB 15 32 41
来源:
中译本<<软件成本估算:
COCOMOII模型方法>>和EstimatingSoftwareIntensiveSystems(Stutzke2005)
经过上述过程,即使是没有技术经验和程序经验的人员,也能够按照一定方法来估算出项目大小了
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 规模 估算