运用UseCase估算工时

  原创作者：zhanghua
转载请注明：来自Sawin系统分析之窗
最后修改时间：2005-2-25

 

摘要：本文介绍了通过UseCase估算项目工时的方法并给出其计算细节，同时还指出该方法存在的问题和不足。

关键词：UUCP，技术因素，环境因素

 

运用UseCase估算项目工时,首先是Gustav Karner本人在其出版的书籍《Applying Use Cases》中提出的。该方法通过利用项目初期产生的UseCase以及分析技术的复杂性和环境的复杂度对项目的工程量进行估算。但是给出的计算细节过于笼统，甚至很多因数亦未提及。因此在实际运用中，有着显著的误差。笔者根据自身的项目实践，参照《Applying Use Cases》中提供的原则，给出采用该方法考虑的要点和具体改进的计算细节，与诸位读者共享。

UseCase法估算项目工程量的步骤如下：

1 生成UseCase

2 Actor权重的计算

3 UseCase权重的计算

4 UUCP计算(UUCP：unadjusted Use Case Point)

5 技术因素权重的计算

6 环境因素权重的计算

7 UCP(Use Case Point)的计算

8 工时计算

   

下面对其进行一一的讲解。

（1）      生成UseCase

将UseCase图进行细化。使得每一个Actor对应且只对应一个UseCase。存在“extend”和“uses”情况时，由于派生或引用的UseCase与外部Actor不发生直接联系,不计入计算式。

 

（2）      Actor的权重

按照UseCase与Actor一对一的原则，根据Actor与UseCase交互时接口的类型，分别给出每个Actor的权重，然后进行合计，得出整个项目Actor的权重值①。具体参考如下:

Actor权重参考表

接口类型	Actor权重
类DOS型界面	0.8
简单的对话型界面	1.6
复杂的对话型界面	2.3
简单的GUI界面	2.4
复杂的GUI界面	3.0

 

Actor的权重合计表

Actor	Actor权重	理由
合计	①

 

 

（3）      UseCase权重的计算

这里指的 UseCase仍是指与Actor直接交互且存在一对一关系的UseCase。根据UseCase包含的事务数（Transaction）与分析类的数目，给出UseCase的权重。然后将所有UseCase的权重相加得出整个项目UseCase的权重总和②。

UseCase权重参考表

类型	意义	权重（系数）
简单型	3个以下事务/4个以下分析类	4～7
平均型	4至7个事务/5至10个分析类	8～12
复杂型	8个以上事务/11个以上分析类	13～17

 

UseCase权重合计表

UseCase名	权重	理由
合计	②

 

 

（4）       UUCP计算(UUCP：Unadjusted Use Case Point)

   将Actor与UseCase的权重相加，即得到UUCP

       UUCP＝∑Actor权重+∑UseCase权重（即①+②）

 

（5）      技术复杂度计算

   将待开发系统所涉及的一些技术因素系数根据涉及程度赋予从0到6之间的值(0：未涉及； 3：一般性；5：本质性)。  

序号	类目	权重	系数	值	理由
T1	分布式系统	1
T2	系统吞吐量大、处理时间短	2
T3	在线用户使用效率高	1
T4	内部处理复杂	1
T5	代码可供后续项目复用	1
T6	易安装调试	0.5
T7	易用性高	0.5
T8	移植性高	2
T9	易扩展和修改	1
T10	并行处理	1
T11	需要特别考虑系统的安全性	1
T12	第三方软件（中间件）能够直接访问	1
T13	需要对用户进行特别培训	1
合计	TFactor=∑权重×系数

由上表得到TFactor的值，根据下面的算式得出该项目技术复杂度的权重

TCF(Technical Complexity Factor)＝0.6 + (0.01×TFactor)

 

（6）       环境复杂度权重的计算

 根据项目开发的具体环境，给下列环境因素的系数赋予0-6之间的值

E1-E4   0无经验，5专家级，3 一般

E5      0 无热情，5 高度热情

E6      0 极端不安定，5不变，3平均

E7      0 无复用   5高度复用（复用度80%以上）

E8      0 效率低下 5开发高度自动化 2 一般

E9      0 公司内/全职开发，5 外包/兼职开发

E10     1 简单开发语言，5 非常难的开发语言， 3 平均

序号	类目	权重	系数	值	理由
E1	开发人员对开发流程的熟悉度	1.5
E2	开发人员对该类应用的开发经验	0.5
E3	开发人员对开发方法的习惯程度	1
E4	项目经理的能力	0.5
E5	开发人员对该项目的热情度	1
E6	开发式样的稳定性（很少变更）	2
E7	该项目的复用程度	2
E8	采用开发工具的开发效率	2
E9	开发人员的来源及工作方式	-1
E10	程序设计语言的难度	-1
合计	EFactor=∑权重×系数

由上表得到EFactor的值，根据下面的算式得出该项目技术复杂度的权重

EF(Environmental Factor)＝1.6 - (0.03×EFactor)

 

注：Karner原著E1所指的是开发人员对RUP（Rational Unified Process）的熟悉程度；E2所指的是开发人员运用面向对象开发方法开发该类应用的经验；E3包括兼职人员

E10：2=Basic/COBOL； 3=C/Pascal(Delphi)/Smalltalk/Java/Eiffel； 4=C++ ；5＝汇编语言

 

（7）       UCP(Use Case Point)的计算

最后根据UUCP，TCF，EF算出UCP

UCP=UUCP×TCF×EF

 

（8）      计算出工时数

计算项目风险系数：

风险系数 = E1-E8中2以下的值与E9-E10中4以上的值的总和

风险系数超过5时，则说明项目的风险非常大，项目失败的概率较大，此时应积极从调整环境因素入手，防止项目失败的发生。

风险系数为3-4时，1UCP对应28-30人时

 

在一般风险（风险系数为1-2时）的情况下，根据Gustav Karner的经验表明：1UCP对应20人时。因此在一般风险的情况下：

工数（人时）＝UCP×20＝20×UCP

以每个人日8小时工作时间计算

工数（人日）＝UCP×20/8＝2.5 UCP

以每个人月160人时计算

工数（人月）＝UCP×20/160＝0.125UCP

         由此可得出整个项目的工程量。

      

整个方法可以总结为：

某某项目工程量（Use Case Point法）

调整前功能量UCCP
技术权重值TCP
环境权重值EF
Use Case Point（UCP）	UCCP×TCP×EF
项目危险系数
在该项目危险系数情况下1UCP对应的人时值（β）
工数（人月）	UCP×β/160

 

讨论：

  采用本方法的优点

（1）      将环境和技术因素进行了量化，克服传统方法在环境和技术因素考虑方面的缺陷

（2）      在项目初期给出项目工数（同FP法）

（3）      能够较客观地反映项目工时数，避免主观臆断

采用该方法的缺点

（1）      Actor较多的情况下，很难确定开发工时数(例：众多带有访问权限的Actor存在的情况下)

（2）      小项目误差较大

（3）      UseCase的权重难以确定

（4）      系数需要由经验的开发人员的估计

 

                        部分项目经验数据

项目	UCP人月	实际人月	UCP人月/实际人月
A	16.0	15.0	1.07
B(自动化工具采用)	4.8	1.0	4.80
C	52	42	1.24
D	50	38	1.32
E	9.2	10	0.92
F	2.0	1.9	1.05

 

一般地，小项目（10人月以下）除外，采用该方法，存在近30%~60%左右的误差（偏大）。误差主要体现在开发工具的使用上和复用程度上，因此根据实际情况可以进行一些适度的调整。该方法比较适合于采用面向对象进行设计的项目。有兴趣的朋友可以试一试和对该方法做一些改进。

 

 

【作者介绍】 zhanghua

张华，国家系统分析员，CSAI高级顾问。先后从事过企业信息管理，项目管理和应用系统分析与设计等工作，能熟练运用多门外语，并在自动化软件生成颇有建树。　　个人熟谙PMI项目管理体系、富士通SDEM方法、IT审计和软件企业信息事业推进，熟悉多种建模方法、设计工具，具有丰富的多种业务领域建模经验。个人目前热切关注的对象有：软件哲学、软件思维工程和知识管理。
作者Email地址：maxwelloracle@hotmail.com