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

用例点表达进度

识别用例的状态

根据生命周期要求,识别用例的状态及转移。

典型的如瀑布型,一般依次有如下状态:用例识别,用例确认,用例已设计,用例已编码,用例已测试。

采用测试驱动开发(TDD)的一个例子,依次状态:用例识别,已写测试用例,用例已编码,用例已集成,用例已测试。

最简化用例状态,依次状态:用例识别,用例已集成。

从以上例子可以看到,传统生命周期和敏捷方法都可以得到合适的状态转移图。

设定用例状态的完成度

完成度以百分比表示,表示与工作量成正比的完成程度,0%表示刚开始,工作量投入为0,100%表示全部已经完成,工作量已经全部投入。

对以上三种状态举例如下。

表5 用例状态完成度例子


瀑布型


采用测试驱动开发(TDD)的一个例子


最简化用例状态


状态


完成度


状态


完成度


状态


完成度


用例识别


20%


识别用例


30%


用例识别


30%


用例确认


30%


已写测试用例


60%


用例已集成


100%


用例已设计


45%


已编码


80%


用例已编码


80%


已集成


90%


用例已测试


100%


已测试


100%

计算折算未完成用例点数UFUCP

为对比进度,将过程中的用例完成情况以折算已完成用例点(FUCP - Finished Use Case Point)来表示,计算公式是 ∑各状态用例数量*用例权重*完成度。以此可计算挣值分析中的挣值。

折算未完成用例点数UFUCP = UCP – FUCP,以此可绘制Scrum中的燃尽图,UFUCP - Unfinished Use Case Point。

一个实际的例子,采用TDD,见表如下:

表6 FUCP例子


模块


用例

大小


各状态的用例数量


U

C

P


折算

已完

成用

例点


折算未

完成用

例点数


识别

用例


已写

测试

用例


已编


已集成


已测试


录入



0


5


1


0


0


75


55.5


19.5



0


1


1


1


0



0


0


0


1


0


查询



5


8


2


0


0


250


146.5


103.5



3


6


1


0


0



0


2


3


0


0


总计


325


202


123

利用折算未完成用例点数UFUCP绘制燃尽图

根据3.3,定期计算UFUCP,可以得到用例点燃尽图,进而直观的管理进度。如图1所示。

图1 用例点燃尽图示例

以上可以看出对于处于过程中、未完成的用例,可以反映其进展,避免了要等到用例实现后才能判断进度,提高了进度管理的准确性和及时性。

时间: 2024-09-30 15:39:20

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

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

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

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

英文名:Based on use case points to measure software size and manage the progress 摘 要 本文针对软件项目的规模度量和进度管理,提出了一种新的以用例点的方式来表达和跟踪的方法.本文具体介绍了经过调整过的用例点度量方法,舍弃了角色相应的用例点数,对用例分类给出了更严格的要求,採用了更仔细的步骤定义,并限制了复杂用例的最多步骤.用例的状态完毕度得到区分,在此基础上建立了过程中用例的进度跟踪方法.最后并阐述了在需求可复用情况下的

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

用例点表达进度 识别用例的状态 根据生命周期要求,识别用例的状态及转移. 典型的如瀑布型,一般依次有如下状态:用例识别,用例确认,用例已设计,用例已编码,用例已测试. 采用测试驱动开发(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.项目监督与控制 项目监控是围绕项目实施计划,跟踪进度.成本.质量.资源,掌握各项工作现状,以便进行适当的资源调配和进度调整,确定活动的开始和结束时间,并记录实际的进度情况,在一定情况下进行路径.风险.决策.度量.量化管理等方面的分析.在实施项目的过程中,要随时对项目进行跟踪监控,以使项目按计划规定的进度.技术指标完成,并提供现阶段工作的反馈信息,以利后续

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

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

常见EDA软件的license管理

大型工程软件如Ansys.Fluent.Unigraph.ProE等安装需要经过注册程序Flexlm才可以使用,而Flexlm中涉及到很多知识.技巧,也存在许多问题.本篇文章就是针对上述软件安装中的常见问题作一些探讨与解决.莱曼特的LMT LicManager可对EDA软件的许可证进行集中监控管理.Lanmantech公司研发的licManager产品充分研究识别Flexlm及其他主流授权机制并利用LMT核心计算模式在不影响软件许可证本身授权机制的基础上对许可证进行闲置识别.资源调度从而提高许可