根据项目用例图用例点估算项目工时的方法

一共通过6个步骤:

1. 计算未调整的角色权值UAW
2. 计算未调整的用例权值UUCW
3. 计算未调整的用例点UUCP
4. 计算技术(TCF)和环境因子(ECF) -> TEF
5. 计算调整的用例点UCP
6. 计算工作量(man - hours)多少人多少工时 (人天)

6步骤之一UAV计算
Actor 角色权值定义:

序号	复杂度级别	复杂度标准	权值
1	simple	角色通过API 与系统交互	1
2	average	角色通过协议与系统交互	2
3	complex	用户通过GUI与系统交互	3

首先分为了三个等级,simple、average、complex,其中通过API交互是最简单的,
就是简单的接口交互,而通过协议的就复杂一些,这里的协议可能包含了如websocket、rpc(protobuf)或者
什么其它的约定协议.
而最复杂的当属通过界面化的形式进行交互,GUI,比如游戏里点击某个按钮或者桌面版本的封装程序界面化的操作.

6步骤之二UUCW计算
Use Case 用例权值定义

序号	复杂度级别	事务/场景个数	权值
1	simple	1-3	5
2	average	4-7	10
3	complex	>7	15

首先还是三个等级,用例中事务/场景个数的多寡来分别对应这三个等级,
比如有个角色ROLE1中的操作要进行A、B、C项基本操作,那么就是simple好了,
但比如还有个角色ROLE2中的操作的场景和要管理的事情多一些,除了ABC基本操作,
还有进行AB的某些汇总计算,C中的某些数据审核,或者AC之间数据的核对确认,那么
就可以归类为average中等级别了.
最复杂的complex等级一般可能见于ROLE_ADMIN,即一些系统终端最终维护角色、
或者对系统要进行全盘操作的角色,那么>7个事务或场景是很有可能的.

6步骤之三UUCP计算
前面两个步骤已经根据角色&用例来计算了UAW和UUCW,
那么这一步就是将未调整的角色权值+未调整用例权值简单加法计算得出UUPC即未调整用例点
比如如图中计算
UAW+UUCW = 25+85 = 110

6步骤之四TCF、ECF计算
TCF: Technical Complexity Factor
这里面一共有13项TCF,每个TCF对应一个权值,其中权值最小为0.5,最大为2.0,即这项技术因子的难度是减半了还是成倍了.而最终进行汇总并与0.01相乘再加上系数0.6.

其中公式中的Value(i)是该技术因子影响的等级,0表示无影响,3表示影响一般,5表示影响是很强的(不能取其它值)

序号	技术因子	说明	权值
1	TCF1	分布式系统	2.0
2	TCF2	性能要求	1.0
3	TCF3	最终用户使用效率	1.0
4	TCF4	内部处理复杂度	1.0
5	TCF5	复用程度	1.0
6	TCF6	易于安装	0.5
7	TCF7	系统易于使用	0.5
8	TCF8	可移植性	2.0
9	TCF9	系统易于修改	1.0
10	TCF10	并发性	1.0
11	TCF11	安全功能特性	1.0
12	TCF12	为第三方系统提供直接系统访问	1.0
13	TCF13	特殊的用户培训设施	1.0

我们从第一个

1. TCF1开始叙述,TCF1分布式系统,这里其实也是根据经验来讲,比如是简单的微服务、一个网关搞定,那么x3,如果是多业务网关包含多子系统模块那么x5.
2. TCF2性能要求简单就是说有几项性能要求,比如客户要很高的系统响应速度,要能快速处理完成非常大数量数据的计算并持久存储结果等等……性能要求没有,就是x0,要求是比较普遍的x3,要求是非常严苛的则x5.
3. TCF3这个要考虑用户使用的效率,其对应的也可能有如系统操作日志多寡、用户操作数据多寡的内容、细想一下用户使用效率,如果开发出来这个系统,最终用户不使用(哈哈),那么x0,使用频率是一般的x3,使用频率很高,并且很多人员都会使用,那么x5.
4. TCF4说明了系统处理复杂度,可以认为有没有复杂的业务,有但一般x3,有但非常复杂x5,简单如一没有复杂业务只是CURD则x0.
5. TCF5则说明是否有相关的以往项目、代码、数据可以拿来及时复用,如果粘过来系统稍微一改马上可以交付,那么x5,没有一点可复用的迹象,x0,有一部分可复用的则x3.
6. TCF6权值较小为0.5,其实就是说是否易于安装,现在这个基本都是必须要求的,那么x3,如果有严格的易于安装的情形x5.
7. TCF7也是0.5的权值,系统易于使用这样的技术因子放在现在也是必须的,基本x5即可.
8. TCF8说明可移植性,因为现在很多编程语言都可以跑在不同的系统,可以说移植难度低了,但是不妨会有转换语言、切换服务器、更换数据库类型、多端访问的问题,比如系统要有PC端、要有IOS、Android端、那么其实从开发效率上来讲是会降低的,所以如果可能有切换服务器、更换数据库类型、多端访问的要求、x5,但是只是多端访问x3,否则没有以上问题x0.
9. TCF9说明系统是否易于修改,也就是代码的可扩展性高不高,代码质量如何,归结下来就是说系统给到其它团队好不好做新功能或维护,一般这项也是必须的x5即可.
10. TCF10并发性,系统少数人用基本x0,有人用,有并发问题但不多x3,并发量巨大x5.
11. TCF11安全性基本也是中大型软件必须的x5,如果没有太严苛的安全要求x3.
12. TCF12是说明该系统还要对外提供接口,多的话x5,不多x3,不提供对外接口x0.
13. TCF13为特殊的用户培训设施,比如系统是对接了一些硬件的,如扫脸、机器人等,并要求进行培训则x5,没有x0.

ECF: Environment Complexity Factor
技术需要技术攻关,团队需要士气和经验,这个ECF是项目成败的另一面.
同样也是x0无关(无难度、无兼职人员、无UML经验等)、x3表示一般,x5表示非常高、多、好(团队成员都具备这种能力).

序号	环境因子	说明	权值
1	ECF1	UML精通程度	1.5
2	ECF2	系统应用经验	0.5
3	ECF3	面向对象经验	1.0
4	ECF4	系统分析员能力	0.5
5	ECF5	团队士气	1.0
6	ECF6	需求稳定性	2.0
7	ECF7	兼职人员比例高低	1.0
8	ECF8	编程语言难易程度	1.0

最终计算ECF汇总和后乘以-0.03最后加1.4.

6步骤之五UCP计算
UCP是调整的用例点,之前是未调整的用例点UUCP,
那么调整公式为:

UCP = UUCP ✖️ TCF ✖️ ECF

即(未调整的功能点)x(技术影响因子)x(环境影响因子)
上图给出的示例是 110x1.02x0.785=88
可以看出技术因素太难攻克,则技术影响越大,工时耗时更久,环境影响因子越大(比如团队士气低下、无相关面向对象经验等),最终调整的用例点则会变得更大,则说明耗时会更久.反正,技术难度影响小,人员经验高对应环境影响变低,调整的用例点更小更少.

PF为每个用例点的消耗工时,这里PF也需要再另行计算估计.

最终用例点估算项目人天的计算公式:

UCP ✖️ PF

例子给出的调整后的用例点是88,PF为20,那么得出1760小时,换算人天为220人天.

最后,220人天除以当时团队的人员数量,即可得出该项目在该团队(环境因子也是评估得该团队)
需要用多少天来完成.

如团队成员8人,则需要27.5天完成.