δ之外,就判定程序评审过程异常。但是缺陷率异常这个质量指标也有可能是其他输入过程异
常而引起的,比如单元测试不全面,测试用例覆盖率低等使得错误遗留到评审过程,导致评审过程的缺陷率高,而评审过程本身没有任何问题。
本文基于软件过程的瀑布模型定义软件过程的两种质量:总质量和分质量。把系统因素细分成“外部系统因素”和“内部系统因素”,并借助于张公绪提出的选控图
[3,4]
来实现两种系统因素的分离,提出在不同的过程参数异常情况下进行过程分析的分析表,以期摒弃外部系统因素对特定过程的影响,实现过程质量性能的独立分析和诊断。
1 软件过程质量指标
对软件过程质量的改进围绕改善软件质量、提高生产效率和降低成本这三方面展开,在这三大类度量的基础上,又可划分为六类的度量:进度、资源和费用、稳定性、质量、开发性能、技术完备性。这六个方面是互相关联的
[7]
。
(
1
)进度,项目按照项目计划时间表的实施情况。进度信息既用于表示实际过程与计划过程的偏差,为过程控制提供依据,同时又用于表示过程发展的趋势,为过程可能遇到的问题或是潜在的问题作出预测。
(
2
)资源和费用,包括人力投入、费用和计算机资源。其中资源是表示建立项目开发环境所需资源,如主机、网络、机时等,在进行软件过程管理时关心计划使用资源与实际使用资源的比较,并基于度量数据动态调整项目的资源分配。
(
3
)稳定性,表示项目运作过程中的变更情况,包括程序大小变更、系统功能规模变更和软件过程变更三方面。用户需求变化直接引起系统功能规模的变更,从而使程序大小产生变更。软件过程稳定性表示过程特性的动态变化是在可控的范围之内,提高软件过程稳定性是通过减少造成过程偏差的系统原因,如员工素质低、没有适当的支持工具等。
(
4
)质量,表示软件产品和软件过程的质量因素,如表
1
所示。
(
5
)开发性能,表示组织的软件生产能力。包括组织的软件过程成熟度级别和软件生产能力。
(
6
)技术完备性,表示技术性因素对软件项目实施的影响。包括人员培训、开发的系统对计算机资源占用、新技术的影响及项目中实施新技术的程度。
表1 软件过程质量度量内容
度量类型
|
度量子类
|
度量元
|
进度
|
里程碑
|
项目里程碑日期
|
单元进度
|
需求的状态及变更请求状态
|
测试用例和覆盖测试的状态
|
软件问题报告的状态
|
迭代效率
|
每一次迭代形成的系统规模的增加
|
资源和费用
|
人员
|
人员投入的工作时间、人员技术经验和人员变更
|
花费
|
各工作单元及总项目的预算花费和实际花费
|
环境资源
|
计划资源与实际资源的数量和质量
|
稳定性
|
产品规模
|
程序代码行数、组件个数及数据库大小
|
功能规模
|
用户需求的规模及软件系统的功能点
|
过程稳定性
|
过程变更请求
|
质量
|
缺陷
|
缺陷数目、缺陷密度及软件失效间隔
|
复杂度
|
圈复杂度和算术复杂度
|
Rework
|
需进行
Rework
程序规模及所需投入的人员
|
SQA
审核
|
过程活动中出现期望值与实际值不一致的频度
|
评审
|
分阶段评审结果和同级评审记录
|
开发性能
|
过程成熟度
|
过程所处的成熟度等级
|
生产力
|
产品规模和功能规模分别与人员投入的比率
|
技术完备性
|
计算机资源占用
|
CPUI/O
内存、存储系统的资源占用和响应时间
|
技术性能
|
满足用户的功能需求和技术性能需求的程度
|
技术影响
|
可重用部件数目
|
培训
|
培训班数目、参加培训员工数及培训过程变更数
|
2 两类变异
从过程偏差对软件过程质量的影响来分,
Shewhart
定义两种影响软件过程质量的偏差源:
l
归因于现象的偏差源(
common causes
),称作偶然因素。偶然因素对过程来说是自然和内在的,是由于过程分量(人、机器、原料、方法、环境)之间正常的或者内在的交互作用导致的性能偏差,是受控的偏差。这种偏差是随机的,不可能彻底消除,但在预定界限内变化。当过程稳定时,可以看到这种随机偏差都来源于偶然原因的恒定系统。可以对软件过程进行持续改进来尽量减轻这种偏差对过程质量的影响,这其实就是
CMMI 5
级的目标。
l
有可归属原因的偏差源(
assignable causes
),称作系统因素。系统因素是可以,而且是应该消除的,是过程本身的一个或者多个分量发生突然或者永久性异常的结果,是非受控的偏差。当排除所有系统因素,并且使之不再发生时,就得到一个稳定的、可预测的过程,这就是
CMMI 4
级的目标。
传统
Shewhart
控制图的实质是区分偶然因素和系统因素所造成的过程波动,确定系统因素,并采取有效措施消除系统因素,使得过程处于受控的稳定过程。控制图的基本形式如图
1
所示,其中:
UCL=CL+3
δ
LCL=CL-3
δ
图1 控制图偏差
对于一个稳定的软件过程,
Shewhart
根据经验认为
3
δ是合理的,这时漏掉系统因素的代价(漏警)和寻找不存在系统因素(误警)的代价是平衡的。Wheeler的经验规则3也说明这个问题:大约99%-100%的数据会处于平均值两边3δ单位距离内。不管过程质量指标的分布情况如何(正态分布、均匀分布、正交分布、指数分布、X2分布等),结果都是如此。在正态分布情况下,数据落在3δ界限外的概率是0.27%。根据小概率事件理论,如果质量指标值在3δ之外,很可能存在系统因素,需要进行排除,以使得数据稳定随机分布在3δ内。
在独立分析软件过程的质量和性能特征时,
Shewhart
控制图和上述两种偏差源分类还是不够的。软件开发的很多不同过程之间是相互影响的,而
Shewhart
控制图是全控图,不能区分其他过程的异常对单个过程的影响,正如引言中例子所言,如果缺陷率异常,难以确定到底是程序评审过程本身的系统因素引起的,还是其他过程的异常带来的。因此,本文把系统因素进一步细分为外部系统因素和内部系统因素:
l
外部系统因素。能对目标软件过程的过程质量属性产生影响的其他过程的有可归属原因的偏差源,包括其他过程的系统因素和偶然因素。由于是非目标过程的偏差源,因此在分析目标过程的质量和性能指标时,需要剔除这种偏差源,实现目标过程分析的封闭性和独立性。
l
内部系统因素。是目标过程本身存在的有可归属原因的偏差源,是可以消除的非正常偏差,也是目标过程的改进重点。
只有真正区分这两种系统因素,才能对软件过程进行独立分析。如何区分这两种系统因素呢?本文使用张公绪
[3,4]
提出的选控图。选控图基本原理如图
2
所示。
图2 选控图原理
在正态分布情况下,假设目标过程的质量指标为
y,
存在
y~N(
μ
,
δ
)
,。假设前序过程的质量指标
x
对
y
会产生影响。则一般有:μ
=F(x)
和δ
=G(x)
。
其中,
F(x)
和
G(x)
可由回归算法、技术分析或者经验获得。由于存在
x
对
y
的影响,假设本过程质量指标
y
的分布是一个正态分布族,传统的休哈特控制图不适合。为了实现区分两种系统因素,对
y
应用标准变化,变换后的
y
标记为
ycs
。
其中
,
表示估计值。当样本足够大时,近似地有
ycs~N(0,1)
,这时,μ
i
=0,
δ
i
=1
,则
ycs
与
x
无关,从而实现了排除外部系统因素的目的。
3 两种过程质量
软件开发活动涉及到很多子过程,每个子过程实现软件产品的一个工序,这些过程是相互关联的,比如引言中的例子。本文以常见的瀑布模型为基础进行分析,如图
3
所示,这是一个简化的软件开发流程图,并认为各个子过程是按照图示顺序执行的。在图
3
中,软件计划过程没有前序过程,此时软件开发过程体现出来的质量特征就是软件计划过程本身的质量性能特征。对于其他过程而言,其所表现出来的质量性能特征都是本过程以及所有相关联前序过程的综合过程质量性能的体现。基于此,我们定义两种软件过程质量:
l
全过程总质量。到目前阶段位置,软件开发活动体现出来的综合质量特征,总质量不仅包含当前第
n
个过程的质量特征,而且综合了所有前序过程的质量特征在内。它是所有已执行过程的各种偏差源的综合作用结果,也可以把目标过程和所有前序过程看作一个集成过程,没有来做于外部的偏差源,只使用
Shewhart
控制图就可以反应集成过程的总质量特征。
l
软件过程分质量。软件过程固有的质量特征,是目标过程本身的质量特征表现,不反应来做于前序过程的影响。在分析软件过程分质量时,必须区分偶然因素、外部系统因素和内部系统因素,尤其是剔除外部系统因素。这时就需要综合使用
Shewhart
控制图和选控图。
在这个理想模型下,对于软件计划过程,由于没有其他前序过程,也就没有外部系统因素,这时总质量就等于软件计划过程的分质量,只使用控制图就可以区分出软件计划过程的偶然因素和系统因素。
对于需求分析过程,总质量是软件计划和需求分析两个软件过程的综合表现,与需求分析软件过程的分质量不同。在分析需求分析过程的过程质量指标时,不仅需要使用选控图来剔除软件计划阶段的影响,还需要使用控制图来区分偶然因素和系统因素,来度量本过程是否稳定,是否符合性能要求。
图3 简化的软件开发过程
4 过程质量分析表
在图
3
中,除了软件计划过程之外,分析其他目标软件过程的总质量和分质量时需要前序过程的控制图、目标过程的控制图和选控图,总共
3
种图。根据控制图和选控图是否异常,存在
23=8
种组合,如表
2
所示。
表2 过程质量分析表
|
前序过程的控制图
|
目标过程的控制图
|
目标过程的选控图
|
分析
|
1
|
异常
|
异常
|
异常
|
目标过程异常(存在内部系统因素),前序过程异常(存在外部系统因素)。
|
2
|
异常
|
异常
|
正常
|
目标过程正常(无内部系统因素),前序过程异常(存在外部系统因素)。
|
3
|
异常
|
正常
|
异常
|
目标过程异常(存在内部系统因素),前序过程异常(存在外部系统因素),但两种系统因素作用相反,目标过程控制图正常。
|
4
|
异常
|
正常
|
正常
|
目标过程正常(无内部系统因素),前序过程异常(存在外部系统因素),但外部系统因素的作用相反,目标过程正常。
|
5
|
正常
|
异常
|
异常
|
目标过程异常(存在内部系统因素),前序过程正常(无外部系统因素)
|
6
|
正常
|
异常
|
正常
|
目标过程正常(无内部系统因素),前序过程正常(无外部系统因素),但两种方向相同而叠加,致使目标过程的控制图异常
|
7
|
正常
|
正常
|
异常
|
目标过程异常(存在内部系统因素),前序过程正常(无外部系统因素),但两者作用相反而抵消,目标过程的控制图正常。
|
8
|
正常
|
正常
|
正常
|
目标过程和前序过程都正常,过程稳定。
|
情况
1
:目标过程的选控图异常,应该查找和解决目标过程的内部系统因素;前序过程异常,应该查找和解决前序过程的系统因素。
情况
2
:目标过程的选控图正常,说明不存在内部系统因素,目标过程的控制图异常是前序过程异常引起的,应该查找和解决前序过程的系统因素。
情况
3
:目标过程的选控图异常说明目标过程存在内部系统因素,应该查找和解决。前序过程的控制图异常说明前序过程存在系统因素,应该查找和解决。目标过程的控制图正常说明内部系统因素和外部系统因素作用相反而抵消。
情况
4
:前序过程的控制图异常说明存在查找和解决外部系统因素,目标过程的控制图正常说明目标过程不存在内部系统因素,并且目标过程的过程质量指标与前序过程的过程质量指标作用相反而抵消,应该查找查找外部系统因素和目标过程中的偶然因素,并加以解决。出现这种情况,也有可能说明目标过程和前序过程之间是松散耦合的,过程之间关联性很弱,前序过程的过程指标异常不对目标过程产生作用。
情况
5
:前序过程正常,目标过程异常,说明目标过程存在内部系统因素,只需要查找和解决内部系统因素即可。
情况
6
:前序过程的控制图和目标过程的选控图都正常,但两者的质量指标方向相反,叠加使得目标过程的控制图异常。这种情况出现原因是前序过程的某质量指标已经靠近控制图的界限,而目标过程的质量指标与上个质量指标作用方向相同,导致目标过程的控制图打点出界,显示异常。
情况
7
:目标过程的选控图异常,前序过程正常,但是与目标过程的质量指标方向相反而抵消,使得目标过程的控制图看起来正常,应该查找和解决系统因素。
情况
8
:前序过程和目标过程都正常,无需进一步处理。
按照表
1
中的判断条件就可以区分针对目标过程是否存在何种系统因素进行诊断。如果分析独立的过程而言,只需要使用控制图即可。
按照表
1
的过程分析表,我们就可以比较轻松识别出当过程的稳定和过程质量属性发生变化,出现异常时,根据控制图和选控图确定导致异常的偶然因素或者系统因素,以及系统因素是外部系统因素,还是内部系统因素,这样就给软件过程的质量分析提供了一种比较粗略的判断机制。
5 结论
软件过程的重要性逐渐引起研究人员和工程实践人员的重视,软件产品质量研究已经比较成熟,但是有关软件过程质量尚处于初级阶段,有很多需要值得研究的地方,借鉴诸如制造业等成熟产业的统计过程控制技术来分析软件过程是一种思路。传统
Shewhart
控制图难以区分和定义过程间相互作用,本文基于简单的瀑布模型,定义软件过程的两种质量,把系统因素细分为外部系统因素和内部系统因素,提出借助于控制图和选控图进行软件过程分析的分析表。这种软件过程质量分析方法使用成熟的统计过程控制技术,能够定性和定量分析软件过程的稳定性和性能等方面质量特性。
参考文献:
龚波
.
能力成熟度模型集成及其应用
[M]
.
北京:水利水电出版社
.
2003
.
龚波、刘卫宏等.软件过程管理
[M]
.北京:水利水电出版社
.
2003
.
张公绪.现代质量管理学
[M]
.北京:中国财政经济出版社
.
1999
.
张公绪.选控图理论与实践
[M]
.北京:中国邮电出版社
.
1984
.
William A.Florac et al
.
Practical Software Measurement: Measuring for Process Management and Improvement[R]
.
Tech Rep:CMU/SEI-97-HB-003
.
William A.Florac,Anita D.Careton
.
Measuring the Software Process-Statistical Process Control for Software Process Improvement[M]
.
Pearson Education, Inc
.
1999
.
John H Baument, Mark S McWhinney.Software Measures and the Capability Maturity Model(CMU/SEI 92 TR 25)[R] .Software Enginerring Institute, Camegie Mellon University.1992.9.