论坛首页 综合技术论坛

软件模块的可测量性

浏览 7700 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2006-09-20  
今天一个朋友看完我的blog, 问我: 你能说说CCOO metric对我们实用主义者的指导作用吗? 我整理了和他的谈话内容,发布在这里。题目就叫软件模块的可测量性(Software Module Measurability)。

Measurability在偏向理性的一些分析方法里面是很重要的。比如marketing里面ROI的分析;客户服务系统里面客户忠诚度的分析。这里我们简单说两个方面。

   1. 怎么做到measurability? 简而言之,当我们明确要测量目标后,接着就是建立数学模型,然后提取特征属性(feature).
   2. 怎么利用measure的结果? 我从两方面来回答. (a) 某次的测量值和预设定的阈值作比较,通常它会警告你某个重大时刻是否到来。(b) 把每次的测量值保存做一个时间序列,那么可以用来调整原来的阈值。不难看出这是一个反馈系统。

下面是我和我朋友的一段对话:

    我: 一般你们什么时候会做refactoring?
    朋友: codes smell bad…
    我: 那么你根据什么来说这些代码是bad smell?
    朋友: 感觉,或者就是可以观察到的…

Well, 我朋友说的感觉,我更多的理解是”经验”。然而经验有时候让决策变得”迟钝”或者”不准确”,因为team member在变,自动化工具在变。但是如果考虑到软件模块的可测量性,有些回答我们可以更加有信心。回到对话场景,决定一个软件模块是否要refactoring. 一般我会去看测试覆盖率的度量,重复代码的度量和前面说的一些OO metric. PM/team leader可以参考这些数据来安排refactoring的schedule.

最后,一个优秀的software team应该:

   1. 保持一份最新的软件模块的可测量性报告.
   2. 分享给每一个team member.
   3. 保持一份最新的schedule.

author: Jack
orignal: http://jack.lifegoo.com/?p=10
   发表时间:2006-09-20  
... ...可测试覆盖率本身和是否需要重构有什么必然得关联呢?
@.@||~
0 请登录后投票
   发表时间:2006-09-20  
Expression 写道
... ...可测试覆盖率本身和是否需要重构有什么必然得关联呢?
@.@||~
我想你是对的,覆盖率和是否需要重构没什么必然的联系:)
0 请登录后投票
   发表时间:2006-09-21  
我觉得在很长的一段时间内,通过一个理论模型(即使这个模型是不断完善的)进行量化的测量仍然不会是主流,主流的估算方式仍然是专家经验.
1.前者成本太高
  虽然CMMI把原来4级的定量管理调整到了2级,但我认为这只是为了迎合传统管理者的胃口,没有可描述可定义的过程,根本就没有一个可以适用的模型,而没有模型指导的数据就是一堆垃圾.

2.软件创新因素太多,重复性少,人员差异大,造成外在环境变化太大,单纯依靠定量估算很容易失真.

0 请登录后投票
   发表时间:2006-09-21  
clamp 写道
我觉得在很长的一段时间内,通过一个理论模型(即使这个模型是不断完善的)进行量化的测量仍然不会是主流,主流的估算方式仍然是专家经验.
1.前者成本太高
  虽然CMMI把原来4级的定量管理调整到了2级,但我认为这只是为了迎合传统管理者的胃口,没有可描述可定义的过程,根本就没有一个可以适用的模型,而没有模型指导的数据就是一堆垃圾.

2.软件创新因素太多,重复性少,人员差异大,造成外在环境变化太大,单纯依靠定量估算很容易失真.

Clamp, 我要表达的主要意思不是说成为主流或者成为决策的主导因素。我觉得应该去动态的理性的跟踪一个项目的状态,至少某些数据能够对你的决策有所参考。当然我们还在慢慢的实践,当进入一个良性循环,我想数据应该可以说明某些方面的问题
0 请登录后投票
   发表时间:2006-09-21  
即使有实验数据出来,我觉得那也是一种参考,而不是标准或者流程的
0 请登录后投票
   发表时间:2006-09-21  
hijack 写道
clamp 写道
我觉得在很长的一段时间内,通过一个理论模型(即使这个模型是不断完善的)进行量化的测量仍然不会是主流,主流的估算方式仍然是专家经验.
1.前者成本太高
  虽然CMMI把原来4级的定量管理调整到了2级,但我认为这只是为了迎合传统管理者的胃口,没有可描述可定义的过程,根本就没有一个可以适用的模型,而没有模型指导的数据就是一堆垃圾.

2.软件创新因素太多,重复性少,人员差异大,造成外在环境变化太大,单纯依靠定量估算很容易失真.

Clamp, 我要表达的主要意思不是说成为主流或者成为决策的主导因素。我觉得应该去动态的理性的跟踪一个项目的状态,至少某些数据能够对你的决策有所参考。当然我们还在慢慢的实践,当进入一个良性循环,我想数据应该可以说明某些方面的问题


恩,关键在于“某些数据”到底是什么?
我个人现在用的项目测量数据只包括以下几个:
    自从第一次正式集成测试以后的内部BUG曲线(分等级)
    自从第一次用户参与的集成测试以后的用户问题曲线(分类)
    这里确定等级和分类是一个很麻烦的事情



0 请登录后投票
   发表时间:2006-09-22  
关于逻辑复杂度。楼主的帖子给出的Link不错,只是简单了些。

条件语句,循环语句都是逻辑分支语句。if else, switch case, for while都代表逻辑分支。
逻辑分支是针对可能执行路径而言的——某一块代码指令是否能够被执行。逻辑分支语句下面的子代码块,有可能被执行(1 – n次),也有可能不被执行(0次)。条件语句if else, switch case,下面的子代码块有可能被执行0次,或者1次;循环语句for while下面的子代码块有可能被执行0次,或者n次。

一个逻辑分支,就代表两条可能执行路径。可能执行路径数目的增长,相对于逻辑分支的个数来说,是指数增长。比如一个method有n个逻辑分支,那么可能执行路径数目就是2的n次方。
注意,if else和if一样,都是一个逻辑分支。所以我们不需要把else的个数计算在内。
同理,
if 
else if
else if
else
这段并列else if的代码里面包含了3个if, 那么有三个逻辑分支。
逻辑分支的个数 = if的个数 + (switch) case的个数 + for, while的个数。
我们只需要一个词语搜索计数工具,就可以查出一段代码包含的逻辑分支的个数。
0 请登录后投票
   发表时间:2006-09-22  
buaawhl 写道

关于逻辑复杂度。楼主的帖子不错,只是简单了些。

条件语句,循环语句都是逻辑分支语句。if else, switch case, for while都代表逻辑分支。
逻辑分支是针对可能执行路径而言的——某一块代码指令是否能够被执行。逻辑分支语句下面的子代码块,有可能被执行(1 – n次),也有可能不被执行(0次)。条件语句if else, switch case,下面的子代码块有可能被执行0次,或者1次;循环语句for while下面的子代码块有可能被执行0次,或者n次。

一个逻辑分支,就代表两条可能执行路径。可能执行路径数目的增长,相对于逻辑分支的个数来说,是指数增长。比如一个method有n个逻辑分支,那么可能执行路径数目就是2的n次方。
注意,if else和if一样,都是一个逻辑分支。所以我们不需要把else的个数计算在内。
同理,
if 
else if
else if
else
这段并列else if的代码里面包含了3个if, 那么有三个逻辑分支。
逻辑分支的个数 = if的个数 + (switch) case的个数 + for, while的个数。
我们只需要一个词语搜索计数工具,就可以查出一段代码包含的逻辑分支的个数。


奇怪,好象帖子串了?
0 请登录后投票
   发表时间:2006-09-22  
没有串,你从楼主的帖子Link看进去,就知道了。
楼上难道没有点进去看?那才是关键。
不过似乎大家都在关注那报告,schedule之类的管理内容。
这也是对的。和老板讲逻辑没用,就要讲这些report,schedule。

除了逻辑分支,更重要的衡量标准是参数的个数。
更准确一些,是整个输入信息的个数,包括参数,用到的成员变量,环境变量。
增加一个输入参数,就是增加了整整一个变化维度。
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics