基于用例点来度量软件规模并管理进度 之中的一个

英文名: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

首先得到用例点数(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

TCF是指 Technical Complexity Factor,技术复杂因数。原UCP方法设计了13个提问,每一个提问都设置了各自的权重,依据提问,给出从0~5的影响值,然后各权重乘于影响值,再取和得TCF。原TCF考查对象是整个估算范围。本文给出的方法是对各模板分别考查,因此採用例如以下简化取值标准。

表2 项目TCF取值标准


权重


标准


0.8


代表简单, 没有技术难点,30%以上部分有參考对象


1


代表一般


1.2


代表复杂有困难,30%以上部分没有先例,须要尝试新技术,比方支持不熟悉的操作系统

第三步 计算ECF

ECF是指 Environment Complexity Factor, 环境复杂因数。原UCP方法设计了8个提问,每一个提问都设置了各自的权重,依据提问,给出从0~5的影响值,然后各权重乘于影响值,再取和得ECF。原ECF考查对象是整个估算范围。本文给出的方法是对各模板分别考查,因此採用例如以下简化取值标准。

表3 项目ECF取值标准


权重


标准


0.8


代表主要开发人员熟悉类似项目,开发人员必须有2年以上的项目经历或作为技术负责人(或主要參与人)经历二个相似项目


1


开发人员必须有1年以上的项目经历或作为技术负责人(或主要參与人)经历至少一个相似项目


1.2


开发人员仅仅有不到1年的项目经历,或没有项目经历,而且没有作为技术负责人经历相似项目

最后一步 计算AUCP

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方法在实践中更为简单,而且分模块考查,更为仔细及准确,得到了实践者的欢迎。

时间: 2024-08-04 07:07:35

基于用例点来度量软件规模并管理进度 之中的一个的相关文章

基于用例点来度量软件规模并管理进度 之三

复用后的规模估算 需求复用 在需求可复用的情况下,识别可复用的用例所占的完毕度.求和可得初始折算已完毕用例点数.规模数据为所实用例点数减去初始折算已完毕用例点数,以折算已完毕用例点数来跟踪进度时,注意起点不为0:假设是绘制燃尽图.起点也不是所实用例点数. 比如:某小版本号的任务是开发实现100个用例点.用例分析已经由还有一个异地团队完毕了,依据两个团队的历史数据和 协定.用例分析所占完毕度为30%.那么初始折算已完毕用例点数为30,这个小版本号的规模是70个用例点. 对于设计复用,也可採用同需求

基于用例点来度量软件规模并管理进度 之一

用例点表达进度 识别用例的状态 根据生命周期要求,识别用例的状态及转移. 典型的如瀑布型,一般依次有如下状态:用例识别,用例确认,用例已设计,用例已编码,用例已测试. 采用测试驱动开发(TDD)的一个例子,依次状态:用例识别,已写测试用例,用例已编码,用例已集成,用例已测试. 最简化用例状态,依次状态:用例识别,用例已集成. 从以上例子可以看到,传统生命周期和敏捷方法都可以得到合适的状态转移图. 设定用例状态的完成度 完成度以百分比表示,表示与工作量成正比的完成程度,0%表示刚开始,工作量投入为

基于用例点来度量软件规模并管理进度 之二

用例点表达进度 识别用例的状态 根据生命周期要求,识别用例的状态及转移. 典型的如瀑布型,一般依次有如下状态:用例识别,用例确认,用例已设计,用例已编码,用例已测试. 采用测试驱动开发(TDD)的一个例子,依次状态:用例识别,已写测试用例,用例已编码,用例已集成,用例已测试. 最简化用例状态,依次状态:用例识别,用例已集成. 从以上例子可以看到,传统生命周期和敏捷方法都可以得到合适的状态转移图. 设定用例状态的完成度 完成度以百分比表示,表示与工作量成正比的完成程度,0%表示刚开始,工作量投入为

Ubuntu 16.04安装基于nethogs衍生的网络监控软件(应用实时网速监控)

基于nethogs衍生的网络监控软件有如下所列举的: nettop显示数据包类型,按数据包的大小或数量排序. ettercap是以太网的网络嗅探器/拦截器/记录器 darkstat通过主机,协议等方式分解流量.用于分析在较长时间内收集的流量,而不是“实时”查看. iftop按服务和主机显示网络流量 ifstat以类似vmstat / iostat的方式通过界面显示网络流量 gnethogs基于GTK的GUI(在制品) nethogs-qt基于Qt的GUI hogwatch带有桌面/网络图形的带宽

基于 Windows GDI 的屏幕录像软件制作过程

我知道,标题不响亮一点你们是不会点进来看的(奸笑),好了言归正传,博主一直都想自己写一个屏幕录像软件,相信大家都用过屏幕录像软件了,专业级别或者商业级别的屏幕录像软件都是自己写驱动来获取显卡数据,或者自己写 Hook 来勾住一些图形函数来获取图形数据等等,不过博主没有这个能耐,唯一可以用的就是 Windows 自带的 GDI 函数了,以前看过一本游戏开发相关的书籍,里面讲解了如何使用 GetDIBits 函数来快速获取 HDC 里面的颜色数据,比起 GetPixel 快了上百个数量级不止,博主灵

基于墨刀的视频编辑软件Xedit 1.0原型化系统

该产品基于墨刀设计,运行环境ios,运行平台ipad,以下是设计思路. 共有登陆.注册.视频.主页.播放.个人信息这六模块. 首先是登陆和注册模块,登陆分为账号登陆和访客登陆,账号登陆可以将用户的视频保存到服务器上,而访客登陆只能将视频保存到用户本地.之后进入主页端,这将是我们的工作目录,在这里我们可以新建项目并导入视频,主页的顶部状态栏共有三个按钮,分别是视频,项目和个人信息.视频用于查看已经编辑过的视频,项目用于查看已经建立的项目,个人信息用于查看账号的信息.演示如下. 接下来我新建一个项目

软件项目量化管理(CMMI高成熟度)实践经验谈——之项目管理过程监督与控制篇

续:软件项目量化管理(CMMI高成熟度)实践经验谈--之概述篇 续:软件项目量化管理(CMMI高成熟度)实践经验谈--之项目管理过程策划篇 2.项目监督与控制 项目监控是围绕项目实施计划,跟踪进度.成本.质量.资源,掌握各项工作现状,以便进行适当的资源调配和进度调整,确定活动的开始和结束时间,并记录实际的进度情况,在一定情况下进行路径.风险.决策.度量.量化管理等方面的分析.在实施项目的过程中,要随时对项目进行跟踪监控,以使项目按计划规定的进度.技术指标完成,并提供现阶段工作的反馈信息,以利后续

基于ASP.NET MVC的快速开发平台,给你的开发一个加速度!

基于ASP.NET MVC的快速开发平台,给你的开发一个加速度! bingo炸了 2017/4/6 11:07:21 阅读(37) 评论(0) 现在的人做事情都讲究效率,最好能达到事半功倍那种效果,软件行业也不例外.但是需求的一再变动,架构和业务功能的一改再改,往往使得软件的开发事倍功半.软件行业急需突破现现状,所以快速开发框架就这么应运而生了.但是市面上快速开发框架种类繁多,今天我给大家带来的是一套界面风格简洁大方.多业务功能.基于ASP.NET+MVC的快速开发框架. 体验地址我会在下文附上

让软件公司的管理多一点“灵魂”(转载)

其管理很可能已经陷入了困境. 什么是管理的灵魂? 如果彼得德鲁克说管理是种实践是对的,那管理的灵魂就必然是一种独立思考的精神,因为唯有独立思考才能完成打穿理论与现实,完成特殊到一般,一般再到特殊这样的轮回. 那如果管理缺了灵魂,那会怎样? 那就会因为失去一种自省的精神,而变得四处都是被分享的成功经验,但其实管理上问题不断. 当一个庞然大物比如:柯达轰然倒下时,人们往往会去反省它可能是管理出了问题.但当它还在时,人们往往会认为是管理支撑了它的存续,而并不能去识别其管理的失败很可能是正在导致肌体的腐