标签：style io os ar 使用 for sp div on
英文名：Based on use case points to measure software size and manage the progress
本文针对软件项目的规模度量和进度管理，提出了一种新的以用例点的方式来表达和跟踪的方法。本文具体介绍了经过调整过的用例点度量方法，舍弃了角色相应的用例点数，对用例分类给出了更严格的要求，採用了更仔细的步骤定义，并限制了复杂用例的最多步骤。用例的状态完毕度得到区分，在此基础上建立了过程中用例的进度跟踪方法。最后并阐述了在需求可复用情况下的使用方式。
用例点 软件规模 进度 度量
Abstract This paper purposed a new method of measuring software size and tracking progress for size and progress management of software project. The detail of use case points counting is illustrated, Use Case Points of the roles are abandoned, Classification of use cases are given more stringent requirements, a more detailed definition of the step is used, and the maximum of steps in the complex use cases is limited. Completion degree of the state of use case is distinguished, and based on this the method of tracking progress of ongoing use cases is setup. And further usage in re-use requirements is also covered.
Keywords Use Case Point, Software size, progress, measure
软件规模度量方面，存在了不少难题：
1，开发语言发展快，最新的IDE可以自己主动生成大量代码
2，维护升级项目的规模难于估算
3，软件复用后的规模难于估算
4，不同软件项目的规模相关的比較
传统软件规模度量採用源码行数，但源码行数有明显的缺点。因此当前在软件行业，发展出了多种软件项目规模的度量方法，较有代表性的例如以下几种：
Function Points 缩写FP
Use Case Points 缩写UCP
User Story Points
本文依据实践，參照原UCP方法[參考文献1]，介绍了一种新的以用例点为单位的软件规模表达方法，并利用这种方法表达软件开发过程中的进度，对上述的问题进行了处理。
首先得到用例点数(UCP- Use Case Points )，原UCP中用例点数由角色的用例点数与用例的用例点数加和得到。本文介绍方法仅仅计用例的用例点数。由于角色的用例点数所占比重非常小，一般不超过2%。
用例点数的计算方法是把用例分成三类，用例分析方法源自于经典用例分析方法[參考文献2]，给予不同权重。
表1 用例分类权重相应表
|
用例类别 |
说明 |
权重 |
|
简单（小） |
基本流的步骤不超过3步，备选流或异常不超过3个。 比方简单用户界面或一般API |
5 |
|
普通（中） |
基本流的步骤有4~7步，备选流或异常不超过6个。 比方普通界面或复杂API |
10 |
|
复杂（大） |
基本流的步骤 8~ 12步，备选流或异常不超过9个。 比方复杂的用户界面或过程 |
15 |
上述说明中的四个关键名词的解释例如以下。
? 步骤——步骤定义为单个角色的原子操作。在一个步骤之内，仅仅说明一个角色的连续动作，角色不发生转移；角色变换，是新的步骤。
? 基本流——也有称为主成功场景，达成用例目标的事件流。
? 备洗流——也有称为失败场景，基本流之外的不能达到用例目标的事件流。
? 异常——在基本流中直接说明的异常情况。
用例分类分析的要点有例如以下。
? 不遗漏，要能全面的反映软件需求，不能有不论什么遗漏的功能。
? 不重复，同样的功能不要重复说明。这会影响数量的统计。
? 考虑所含信息要充分。
? 都能够被黑盒測试。
? 一般的API用例，即使过程较为复杂，还是简单用例。
? 备选流和异常数量多时，提升用例的复杂度。
? 某一步骤是特别复杂（如一个步骤中角色的连续动作超过5个），提升用例的复杂度。
? 用例基本流步骤超过12步，分拆用例。
依据以上相应表和规则，对用例进行识别，然后把计算出各类别的用例数量，分别乘以权重，取总和就得到用例的用例点数。公式为：
UCP = ∑ 各类型用例数量 * 相应的权重
TCF是指 Technical Complexity Factor，技术复杂因数。原UCP方法设计了13个提问，每一个提问都设置了各自的权重，依据提问，给出从0~5的影响值，然后各权重乘于影响值，再取和得TCF。原TCF考查对象是整个估算范围。本文给出的方法是对各模板分别考查，因此採用例如以下简化取值标准。
表2 项目TCF取值标准
|
权重 |
标准 |
|
0.8 |
代表简单, 没有技术难点，30%以上部分有參考对象 |
|
1 |
代表一般 |
|
1.2 |
代表复杂有困难,30%以上部分没有先例，须要尝试新技术，比方支持不熟悉的操作系统 |
ECF是指 Environment Complexity Factor, 环境复杂因数。原UCP方法设计了8个提问，每一个提问都设置了各自的权重，依据提问，给出从0~5的影响值，然后各权重乘于影响值，再取和得ECF。原ECF考查对象是整个估算范围。本文给出的方法是对各模板分别考查，因此採用例如以下简化取值标准。
表3 项目ECF取值标准
|
权重 |
标准 |
|
0.8 |
代表主要开发人员熟悉类似项目，开发人员必须有2年以上的项目经历或作为技术负责人（或主要參与人）经历二个相似项目 |
|
1 |
开发人员必须有1年以上的项目经历或作为技术负责人（或主要參与人）经历至少一个相似项目 |
|
1.2 |
开发人员仅仅有不到1年的项目经历，或没有项目经历，而且没有作为技术负责人经历相似项目 |
AUCP是指Adjusted Use Case Points。
首先以模块为单元来进行归类，识别模块的TCF和ECF，得到模块的AUCP，再合计得到总的AUCP。公式为AUCP = ∑UCP * TCF * ECF。见下计算表格表4为例。
得到了总的AUCP后，就能够依据生产率来估算所需的工作量。
表4 UCP计算表格样例
|
模块 |
用例 |
UCP |
TCF |
ECF |
AUCP |
||
|
简单 |
普通 |
复杂 |
|||||
|
录入 |
6 |
3 |
1 |
75 |
1 |
1.2 |
90 |
|
查询 |
15 |
10 |
5 |
250 |
0.8 |
1 |
200 |
|
总计 |
|
|
|
325 |
|
290 |
|
说明：原UCP方法是计算得到UCP总和后再乘以TCF和ECF，TCF和ECF都是考查估算范围总体情况，分别仅仅有一个值。本文给出的调整UCP方法在实践中更为简单，而且分模块考查，更为仔细及准确，得到了实践者的欢迎。
标签：style io os ar 使用 for sp div on
原文地址：http://www.cnblogs.com/gcczhongduan/p/4060151.html
