软件评审过程度量（共4篇）
软件评审过程度量 篇1
0 引言
随着软件复杂程度和规模的增长, 软件开发成本和周期相应不断增加, 引发是软件开发风险的增加, 软件质量很难得到有效的控制[1]。为能够生产高质量、低成本、周期短的软件产品, 企业越来越重视评审在软件开发过程中发挥的作用[2]。评审的目的就是找出可能影响软件产品质量、以及在开发过程、维护过程的试用性和环境方面的设计缺陷, 同时采取补救措施, 找出在性能和经济方面的可能改进。虽然评审不能从源头上解决软件开发中存在的成本和缺陷产生的问题, 但在软件过程管理和持续改进方面起到的作用却是不能被忽视的。
1 基本理论
软件能力成熟度模型集成 (CMMI) 其所依据的想法是:集中精力持续努力去搭建有效的软件工程过程基础结构, 不断进行过程改进和管理实践, 克服软件开发中的困难。软件评审过程度量的应用主要是采用软件度量学的方法对软件评审质量进行科学评价, 通过量化管理和监控软件开发过程, 合理分配资源, 修定有效可行的软件开发计划, 在提高质量的同时降低软件开发成本[3]。这种软件过程质量的量化管理为软件评审过程的持续改进奠定了基础, 也为管理层对项目后期如何开展提供参照依据。文章使用主成分分析法通过研究软件评审度量指标体系的内在结构关系, 将多个评审度量指标转化为少数几个相互独立且包含原来指标大部分信息 (86%以上) 的综合指标。其优势在于确定的权数是基于数据分析而得出的指标之间的内在结构关系, 不受主观因素影响, 具有较好的客观性, 而且得出的综合指标 (主成分) 之间相互独立, 减少信息的交叉, 这对软件评审的分析评价极为有利。
2 软件评审
2.1 评审流程
软件评审分为4类:管理评审、同级评审、项目后的评审、状态评审, 文章重点研究同级评审, 同级评审流程图如图1。
同级评审最终输出《评审检查表》和《评审报告》。
2.2 评审过程的质量因素
同级评审的目标是发现缺陷, 其中包含预审提交的缺陷数量和评审后确认的缺陷数量。鉴于评审工作产品的规模和类型不同, 不以绝对的缺陷数量来评价评审质量。在评审过程中搜集了15项度量元, 整合为7个度量要素, 软件评审过程质量要素分解表如表1所示:
3 主成分分析法
主成分分析是设法将原来众多具有一定相关性指标 (比如P个指标) , 重新组合成1组新的互相无关的综合指标来代替原来的指标。通常数学上的处理就是将原来P个指标线性组合, 作为新的综合指标。最经典的做法就是用F1 (选取的第1个线性组合, 即第1个综合指标) 的方差来表达, 即Var (F1) 越大, 表示F1包含的信息越多。因此在所有的线性组合中选取的F1应该是方差最大的, 故称F1为第1主成分。如果第1主成分不足以代表原来P个指标的信息, 再考虑选取F2即选第2个线性组合, 为了有效地反映原来信息, F1已有的信息不需要再出现在F2中, 用数学语言表达就是要求Cov (F1, F2) =0, 则称F2为第2主成分, 依此类推可以构造出第3、第4, ……, 第P个主成分[4]。
3.1 主成分模型
主成分模型:
须满足以下条件:
(1) 每个主成分系数平方和为1, 即:
(2) 主成分之间互不相关, 即:
(3) 主成分方差依次递减, 即:
3.2 主成分分析法综合评价模型的具体步骤
3.2.1 评审度量数据采集及相关系数矩阵
根据表1所示的度量要素和计算公式, 搜集某企业21个同行业软件项目 (P1至P21) 的评审相关度量数据。将软件评审度量数据进行标准化处理, 把数据转换为标准正态分布, 计算相关系数矩阵, 反馈出各指标之间的相互关系 (表2) 。
3.2.2 特征方程及主成分确定
通过统计产品与服务解决方案软件 (SPSS) 进行运算分析, 得到软件评审度量指标的相关系数矩阵特征值及其对应的特征向量 (见表3) 。一般取特征值大于或等于1, 累积贡献率大于85%的因子作为主成分[5], 由表4看出, 提取4个综合因子可以基本反映全部指标的信息, 可以描述原变量信息达到87.4%。
通过表4所示的主成分载荷情况, 需求的确认度、需求的无二义性在第1主成分上载荷值较大, 与第1主成分的相关系数较高, Y1反映了需求识别能力, Y1得分越大, 表示项目的需求识别能力高;评审缺陷识别率、问题处理率和评审阶段缺陷排除率在第2主成分上的载荷值较大, Y2反映了缺陷排除能力, Y2得分越大, 表示项目的缺陷排除能力强;缺陷密度在第3主成分上的载荷较大, 相关程度较高, Y3反映了问题发现能力, Y3得分越大, 表示项目的问题发现能力强;评审人力率在第4主成分上的载荷较大, Y4反映了评审人力效率, Y4得分越大, 表示项目的评审人力效率高。
3.2.3 主成分值以及综合分值
运用SPSS软件进行主成分分析, 运行生成因子成分得分系数矩阵和模型, 得到各主成分线性组合模型:
式中:X1, X2, X3, X4, X5, X6, X7分别指评审缺陷识别率、评审人力率、问题处理率、需求的确认度、需求的无二义性、评审阶段缺陷排除率、缺陷密度的标准化指标。Y1, Y2, Y3, Y4分别指软件评审度量指标的第1, 2, 3, 4主成分值。
3.2.4 评价等级及数据分析
依据各主成分线性组合模型, 计算每个项目的主成分值, 并按得分值的大小进行排序, 得到21个项目的4个主成分得分矩阵 (表5) 。
根据主成分得分矩阵可以得出:21个项目在软件评审过程中的需求识别能力、缺陷排除能力、缺陷发现能力、评审人力效率的相对水平, 也能够反馈出项目的评审执行效率。数据的差异反应了项目在评审过程中的需求识别能力、缺陷排除能力、缺陷发现能力、评审人力效率等方面的差异。依据表5的数据分析:首先确认项目的需求识别能力评价分值为正, 即在需求分析充分的条件下, 依据缺陷排除能力、缺陷发现能力评价分值的大小判别项目在缺陷排除及发现的水准。评审人力效率的评价分值大小直接反映评审过程的工作量水平。通过以上数据分析找出评审过程中的薄弱环节加以改进, 在实践中检验其可行性, 为项目后续工作的有效开展提供参照和建议。文章采用的主成分分析法根据各度量指标的贡献率大小确定, 不仅克服人为确定权重的缺陷使得综合评价结果唯一, 而且客观合理。
4 结束语
通过对评审质量的分析, 可以发现评审过程中可能存在的不足, 以便提前采取有效措施来降低评审产生的不利影响, 同时也可为后期的过程改进提供建议。软件评审过程的度量分析结果反映评审过程的运作情况, 经过数据分析、过程评价、过程控制及过程改进, 进而不断地完善评审体系, 达到提高评审质量和降低评审成本的目的。评审过程质量的度量方式有很多, 研究侧重点也不尽相同, 这就需要人们继续研究和持续改进, 软件评审过程质量的度量分析工作还具有更为广泛的研究前景。
摘要：软件能力成熟度模型 (Capability maturity model integration, CMMI) 被众多企业重视及推广应用, 这不仅体现一个软件开发单位的CMMI等级, 而且可以帮助软件开发单位进行自我检验, 不断优化单位的软件开发过程, 提高软件质量, 软件开发效率, 提升客户对产品的满意度。文章依据CMMI相关过程域对软件评审过程度量的支持框架, 参照企业实际情况进行评审过程质量的度量分析, 运用传统的过程度量方法以及统计技术对软件评审过程度量进行研究。
关键词：软件能力成熟度,软件评审,质量因素,软件评审过程度量,主成分分析
参考文献
[1]侯红, 丁剑洁.软件度量与软件过程管理[M].北京:清华大学出版社, 2009:40-41.
[2]张万军, 郑宁, 赵宇兰, 等.基于CMMI的软件工程及实训指导[M].北京:清华大学出版社, 2011:74-152.
[3]李健.软件过程质量度量与控制[M].北京:清华大学出版社, 2005:56-68.
[4]于秀林, 任雪松.多元统计分析[M].北京:中国统计出版社, 1999:78-143.
[5]张文霖.主成分分析在SPSS中的操作应用[J].市场研究, 2005 (12) :31-34.
软件过程中同行评审的应用与度量 篇2
软件过程是CMM/CMMI中的基本概念之一,它由一系列的子过程组成,典型的子过程包括:需求分析、设计、构造、测试、同行评审、软件质量保证(CMMI中为“过程和产品质量保证”)、软件配置管理(CMMI中为“配置管理”)、项目管理等。其中,同行评审(Peer Review)几乎贯穿整个软件生命周期,自始至终扮演着重要的角色。然而,CMM/CMMI只提出了要做什么,而没有说明如何去做。
我国众多软件企业中同行评审的应用可以说既不广泛也不深入,对同行评审的量化控制研究得也比较少[1]。这有认识和文化上的原因,也有方法和应用上的原因。针对这种现况,本文以CMM/CMMI为基础,探讨软件过程中同行评审的方法与度量等。
1 同行评审的应用
同行评审是CMM三级中的一个关键过程域[2],它在CMMI中得到了更高抽象,作为一种质量控制活动对应CMMI的“验证”[3]。
同行评审是由工作产品的作者自发地邀请遵守明确定义的过程的一组同行对其刚完成的工作产品(全部或一部分)进行检查、以发现缺陷的一种方法。
在软件过程中,同行评审是尽早发现缺陷的一种最佳实践方法。它可以促进对工作产品及可预防缺陷更好地了解,从而提高软件工作产品的可靠性、可用性、可维护性;它还可以促进对软件过程信息的采集与使用、提升组织过程质量、降低组织风险和软件开发成本、提高生产率。此外,同行评审也有助于参与者通过评审其他人的输出产品来提高自己的技能,给参与者以参与感、认同感和成就感,有助于组织内部知识共享,加强团队精神。
1.1 同行评审与测试的差异
测试是软件过程中广泛应用的另一种发现缺陷的方法。与测试相比,同行评审具有以下优点:
(1) 适用面广 测试只能识别可执行系统中的缺陷,而同行评审更通用、适用对象更广,它甚至可用于不能被执行的文档或其它工作产品(参见本文1.4)。
(2) 成本低 在软件过程中,越早发现并修复缺陷,其发现与修复的成本越低,对以后的影响也越小,同时还可预防类似缺陷的引入。因此,早期发现和修复缺陷比到测试阶段才发现和修复缺陷的成本要低很多倍。同行评审能在软件过程起始阶段就实施,从而尽早发现缺陷、排除缺陷。所以,同行评审更加经济。
(3) 效率高 同行评审发现缺陷的效率一般比测试发现缺陷的效率要高(尤其在类似可维护性、可移植性等软件质量属性方面,其发现缺陷的效率更高,这是因为测试通常更关注于功能性),从而还可以提高生产率。
1.2 同行评审与技术评审的差异
技术评审与同行评审相类似,它是邀请在该领域具有丰富知识和经验的资深人员对某些关键性的、重要的工作产品进行正式评审,以确保此工作产品达到一定的标准。
同行评审与技术评审的差别主要有:
(1) 目的不同 同行评审是为了尽早发现缺陷,不存在是否“通过”评审;而技术评审的目的则不仅仅是发现缺陷,更重要的是评审工作产品是否达到标准、是否可以通过审核、继而进行下一步工作。
(2) 发起人不同 同行评审一般都是作者自发地发起的活动;而技术评审往往是根据组织规定应当或必须进行的活动。
(3) 评审人不同 同行评审邀请的评审员与作者无论知识、技能、经验还是技术或管理级别都基本相当,作者与评审员没有层次和等级之差;而技术评审邀请的评审员应该在相关领域有非常丰富的经验、具有一定权威性,与作者相比往往较高的技术级别和管理级别。
(4) 时间点不同 同行评审可以在软件过程中任何时间点进行,技术评审则在确定的时间点进行。而且,同行评审常作为技术评审的输入。
1.3 同行评审的方式
最早的同行评审是检视(Inspection),是Fagan在IBM提出的[4],它以定义好的结构化的评审过程、适宜的检查表、定义参与者的角色、表格和报告等为基础。这是最严格的一种同行评审,也是被业界认可的同行评审最佳实践。
同行评审还有多种形式,其中,应用较普遍的是走查和传阅,它们和正式检查相类似但有所差别。走查是一种非正式的同行评审,由工作产品的作者向同行描述产品,请求他们的意见,参与者没有明确的角色之分;传阅也是一种非正式的同行评审,是作者将工作产品分发给同行,请求就某方面进行检查,参与者没有角色之分。
同行评审的多种方式中,检视是形式最正式、过程最完整的一种方式。本文将以检视为例来介绍同行评审及其度量。
1.4 同行评审的适用对象
同行评审适用于软件过程中产生的任何可阅读的工作产品,包括:软件(如源代码)和非软件工作产品(如需求规格说明书等文档)、可交付的和不交付的软件工作产品。
同行评审也适用于软件过程改进中的任何工作产品,包括:过程描述(如流程和剪裁标准)、过程记录(如记录模板)。
软件项目应该在项目计划阶段就确定将经受同行评审的软件工作产品,并且在项目计划中有明确的记录。为达到良好的质量水平,建议每一个纳入配置管理的软件工作产品都至少进行一次同行评审。
1.5 同行评审的参与者
同行评审中的“同行”指的是与作者的工作领域和级别等相当、具备一定的产品知识和软件经验的人。
一般情况下,参加同行评审的人员有3～7人,角色分为主持人、作者、记录人、评审员等。如果由于人力资源的限制或其它原因,有的人员可以兼任其他特定的角色,例如:主持人可以兼任评审员、作者也可以是评审员。但是,原则上作者不可以兼任主持人,也不建议主持人和记录人由同一个人担任。为了取得良好的评审效果,一般建议至少有两名评审员。
所有参与同行评审的人员都应该经受必要的同行评审过程与方法的培训。而且,评审后将依据培训流程的规定给他们增加相应的记录和经验值。
1.6 同行评审的流程
同行评审的完整过程是由策划、介绍会议、准备、评审会议、后续跟踪等多个子过程组成。其流程如图1所示。
策划 策划同行评审工作,首先需要选定评审小组成员与角色、确定评审日程、制订或选择恰当的评审检查表,然后分发会议通知、被评审资料和评审检查表等。
介绍会议 如有必要,召开一次介绍会议,由作者向评审小组介绍被评审资料概况、特性和评审检查表的使用方法等。
准备 参加同行评审的人员阅读被评审资料,依据评审检查表进行检查,记录问题与工作量,为评审会议做充分准备。
评审会议 召开评审会议,各评审员发表自己的评审意见、提出记录的问题,进行讨论,但不探讨如何解决问题,只在会上确认缺陷。一般会议时间控制在两小时以内。
后续跟踪 评审结果分析、缺陷修复和跟踪等后续工作。
2 同行评审的度量
CMM中,同行评审这个关键过程域对度量的描述如下[2]:“进行度量并将度量结果用于确定同行评审活动的状态。度量的例子有:所完成的同行评审数与计划相比较、同行评审所花费的总工作量与计划相比较、被评审的工作产品数与计划相比较等。”
2.1 同行评审的度量过程和指标
一个软件组织在计划度量时,应该具体说明何时、何人、对什么度量项、如何进行度量。概况起来,我们的同行评审度量过程是:在策划阶段由主持人和作者制订计划,在同行评审计划总结表中填写计划数据;后续跟踪阶段,记录人记录并整理同行评审过程的原始数据;质量管理人员收集、核实并处理这些数据,对同行评审进行度量和评估,并将结果提交配置管理部,同时向管理层报告。
以下是在每次同行评审结束之前都进行度量的指标:
评审工作量 每个参与同行评审人员在同行评审各项活动中所花费的时间的总数。
评审成本 评审工作量乘以单位工作量的成本。
严重缺陷数 评审发现的严重度为“非常严重”和“严重”的缺陷总数。
一般缺陷数 评审发现的严重度为“一般”和“待加强”的缺陷总数。
缺陷总数 评审发现的严重缺陷数与一般缺陷数的总和。
缺陷密度 被评审工作产品的规模以“页”或“千行代码(KLOC)”为单位,缺陷总数除以工作产品规模就是缺陷密度,其单位一般是“缺陷/页”或“缺陷/KLOC”。
评审速度 被评审工作产品的规模除以所投入的工作量。
评审效率 此次同行评审发现的缺陷总数除以所有评审人员的所有评审活动的总工作量。
2.2 同行评审的能力基线
当组织中进行了若干次同行评审并收集到它们的度量数据后,就可以建立同行评审的能力基线。
下面是收集某组织中一段时期以来评审对象均为过程文档的同行评审数据,并对原始数据进行处理、分析的方法和过程。
对表1中的原始数据进行处理,处理结果见表2。
表2中:
· PLOT就是表1中的评审效率;
· CL(Control Limit)=同行评审的缺陷总数 / 同行评审的总工作量;
· UCL(Upper Control Limit)=CL+3(SQRT(CL/A(1));
· LCL(Lower Control Limit)=CL-3(SQRT(CL/A(1)),当计算出的LCL为负时,使LCL = 0.00;
· A(1)就是表1中相应的工作量数值。
依据表2绘制出同行评审效率控制图,如图2所示。
从图2可以看出,各次同行评审效率都在控制线之间,数据也是有效的,这说明该组织的同行评审过程是稳定的。通过这一方法也就得到了图2所示的组织同行评审效率能力基线。
当整个软件过程结束时,还可以进一步做总体的度量和横向的对比,例如:同行评审与其它发现缺陷的活动(如测试)的有效性度量和对比。
3 结 论
同行评审是一种非常有效的发现缺陷、获取软件过程信息的方法。国内软件组织应该以CMM/CMMI为指导引入同行评审,在软件过程中建立一个文档化的同行评审规程,并且明确度量指标、方法和过程等。在广泛应用同行评审并收集数据基础上,利用度量结果来评估和改进软件开发过程、提升软件组织能力,才能事半功倍!
参考文献
[1]刘亦书.CMM/CMMI中同行评审子过程的定量控制.计算机工程与设计,2004,25(6):978-981.
[2]M.C.Paulk,et al.Capability maturity model for software v1.1.LosAlamitos,CA,USA:IEEE Computer Society Press,1993.
[3]CMMI Product Team.Capability maturity model integration v1.1.LosAlamitos,CA,USA:IEEE Computer Society Press,2002.
[4]M.Fagan.Design and code inspections to reduce errors in program de-velopment.IBMSystems Journal,1976,15(3).
[5]W.S.Humphrey.软件过程管理Managing the software process.北京:清华大学出版社,2002.
基于CMMI的软件过程度量 篇3
关键词：软件过程,度量,CMMI
1 介绍
过程管理已经逐渐成为了现代软件质量管理的核心,从二十世纪七十年代开始,就不断涌现出了各种软件过程质量模型和软件质量标准[1],包括CMM[2]、CMMI[9]、ISO9001[3]、SPICE[4]等。虽然,上述各大模型和标准都不尽相同,但它们都不约而同地把关注点放在了基于度量的软件过程改进之上。也正因为如此,目前,过程度量已经成为了软件过程能力度评估和管理的重要组成部分。
然而,CMM、CMMI等模型都没有精确定义实施软件过程度量以及收集并分析软件过程数据的方法,也没有指明应该使用何种工具及方法完成相关的度量操作。因此到目前为止,各企业只是按照自己的理解来进行软件过程度量,仍未有一种操作标准和指南来帮助企业有效地实施相关的度量活动。
基于已有的CMMI模型,本文将提出一个用于软件过程度量的过程模型,并对其相关的活动、方法等内容进行定义。本文还将介绍与常用数据收集、认证和分析过程有关的目标、任务和方法,以便更好地使用过程度量模型实施软件过程度量。之后,还会给出一个使用该模型进行实际评估和改进的实例。
文本的组织结构如下:
第二部分将描述针对软件过程度量的过程模型,定义相关的内容、主要活动以及方法等;
第三部分将介绍在数据捕捉(收集和验证)及分析时的目标、任务和方法;
第四部分将给出一个基于提出模型的过程评估及改进实例;
最后第五部分将对全文做出总结并给出今后拟进行的研究工作。
2 软件过程度量
所谓过程度量,是指在某种限制条件下由多个角色根据(过程)计划所进行的一系列(度量)活动[3]。因此,过程度量本身也便成了一种“过程”。图1是在CMMI的基础上给出的一个软件度量过程模型。该图中包含了每一个过程度量活动中的输入、输出、限制条件、必备的支持工具及方法等。这当中,每一个活动的输入指的是来自于前一个活动的数据输出或其它相关的外部输入,正是由于这些输入,使得度量的分析结果可以很好地反映出过程的执行情况,从而确定出在过程执行期间是否满足了那些关于过程评估、过程控制和过程改进的既定目标[8]。
2.1 过程度量的输入和输出
软件过程度量的对象是软件过程的活动和相关的工作产品,因此,软件过程度量的输入就应该是软件项目小组每天的生产活动和对应于每一个阶段的有关产品。另一个可以作为输入的是软件过程度量计划,该计划是软件项目小组根据组织及项目目标并在GQM(Goal-Question-Metrics)度量模型[6]的指导下按照项目实际环境建立起来的。软件过程度量必须与其要度量的软件过程相联系,相关的度量活动则经常与相应的软件过程并行展开,因此,过程度量计划往往会被视作为一个项目计划的一部分。
2.2 过程度量的主要活动
软件过程度量包括了数据捕捉和度量分析两部分。其中,数据捕捉包含了两个活动:数据收集和数据验证,而度量分析则由三个活动组成:数据转换、度量分析和决策制定。
2.3 过程度量的体系结构
软件过程度量的体系结构包括一些核心的业务模块、支持工具、度量数据库以及一些相关的规则、方法、指导、模版等。核心的业务模块可以完成一些如数据收集、数据分析、数据存储以及信息反馈等的核心功能,各类支持工具则可以向各业务模块提供必要的原始过程及产品数据。如图2所示,是一个简化的软件过程度量体系结构。
根据度量请求,度量规划模块会按照GQM的标准格式生成一张与该项目相对应的度量进度表。在制定进度表的时候,该模块会采用已知的度量模型并选取以往的项目经验进行参考。在度量进度表中,针对最终信息产品的的进度信息会根据在请求中包含的相关需求信息(如内容、时间等)产生,针对分析功能的进度信息会根据决定最终信息产品的度量模型产生,针对数据收集的进度信息会根据度量模型中对基本度量数据的要求以及相关的评估和度量步骤产生。
数据分析模块负责加工相关的信息产品。根据来自于度量规划模块的进度信息,数据分析模块会在适当的时间点采用某些分析模型、加工基本的度量数据、创建相应的信息产品并把它提交到信息反馈模块。
信息反馈模块负责把相关信息产品反馈给请求者。完成反馈的途径有很多种,可以在Web上进行显示,可以被打印出来,也可以通过电子邮件的方式进行发送。
度量数据往往存储在度量数据库中。历史度量数据库中存储的是以往度量活动中产生的度量产品和相关的度量经验。度量模型数据库中存储的是各类度量模型的详细信息,包括使用的分析模型、适应性条件、基本度量数据等。当项目结束时,所有模型数据库中的信息会被转存到软件组织的历史度量数据库中。
3 数据收集和度量分析
考虑到企业及组织内部的多样性,列写并评估所有与度量过程有关的详细方面和内容是不现实且无意义的[3]。本文把度量并改善软件过程作为首要目标,因此决定选择软件规模、工作量、项目进度、成本及软件缺陷作为主要的度量因素。通常,可以用功能点、代码行、文档的页数来衡量软件的规模,用人时、人天等来表述工作量。项目进度反映了实际每一个工作阶段的开始及结束日期。而软件缺陷则按照严重度等级、生产阶段以及不合格内容的类型分别进行计算和统计。由于上述的所有度量点都直接或间接地与工作量有关,所以下文拿工作量度量作为例子来介绍与软件过程度量有关的各个活动阶段。
3.1 数据捕捉(数据收集和验证)
软件项目的实际过程数据一般来自于项目日/周报和针对软件产品的评估及测试报告。而关于工作量的信息则一般来自于员工的工作日记。
项目经理必须负责每周统计出项目中每一个任务的执行情况并如实填写《项目状况报告》,包括每一个任务的实际工作量、成本、规模、缺陷信息以及为修正这些缺陷所需的额外工作量等。当项目的每个阶段结束时,项目经理必须总结该阶段的所有过程数据并完成《项目情况总结报告》以记录与项目该阶段有关的所有度量数据,包括实际工作量、规模、进度以及该阶段的实际情况与预计成本、计划的偏离程度。在每一周和项目的每一个主要里程碑上,项目经理必须跟踪缺陷的关闭情况并确保项目数据在由SQA评估及验证之后被存入过程数据库中。来自于项目开发的数据必须至少包括如下信息:
1)需求定义、设计、编码和测试等阶段所需的预计时间和工作量;
2)项目管理、质量保证、工作产品评估、配置管理、培训等阶段所需的预计工作量;
3)在开发阶段的初期所确定的需求数量以及后续增加或更改的需求数量;
4)开发过程中及其后所记录的缺陷数量,即,在需求定义、设计、编码、测试以及系统测试之后等阶段中所发现的不同类型、不同严重度的缺陷数;
5)基于干代码行技术或功能点计算等方法的针对项目规模的预测。
3.2 过程度量分析
实施度量分析的目的是为了发现现存软件过程中的问题并定义出过程改进的计划和目标。过程度量分析的关键是对实际工作量、项目进度、项目实际情况与计划或预计成本的偏离程度、过程中存在的缺陷以及在项目中已解决的缺陷进行分析和统计。因此,必须首先按照特定的数据模型提取并统计现存的过程数据,使其能够很好地反映出度量的范围和目标,然后,再把经过转换的数据同使用相同格式的基准参数进行比较,以发现被度量过程中存在的问题并把其作为过程改进的依据和基础。
表1是一个在通过CMM3级认证的软件公司中使用的针对软件过程度量的统计数据模型。文中的项目数据是由组织的软件过程能力度和实际的项目情况所决定的。当项目结束的时候,项目经理、软件工程过程小组以及软件质量保证人员就可以根据项目的评估数据和实际的项目过程数据并使用表1中所示的过程度量数据模型对相关的数据进行转换和解释。
4 过程度量应用实例
基于度量过程的相关定义以及上述的统计数据模型,下文将介绍一个针对中等规模财务软件开发过程开展度量和分析活动的实例。其中,那些用于度量的数据来自于公司员工的工作日记、缺陷评估清单、软件测试记录、用户反馈记录等,并在经过项目经理的确认以及质量保证人员的验证之后被实时地录入到公司的数据收集系统之中。根据每一个项目、任务和工作阶段的编号,项目经理可以很方便地使用数据收集系统统计出关于每个任务、每一阶段及整个项目的实际工作量、人员工作时间、成本以及缺陷数据等信息。表2与表3中列写的就是针对该项目度量数据的统计结果。为了对项目的过程进行评估及分析,表2中还列出了与相关度量数据对应的组织基准参数。
由于并未设立组织内部针对缺陷的基准参数,因此,表3只是列写了项目中的一些关于缺陷的实际度量数据,并按照发现并修正缺陷的阶段对这些数据进行了分类。
通过比较和统计上述的度量数据,可以得到如下针对该项目软件过程的分析和评估结果:
1)如表2所示,项目进度和工作量的偏差对应于基准参数各增长了68%和80%,而需求稳定度和编码方面的工作量又基本与相应的基准参数保持一致,因此,项目工作量的增加和进度的延迟并不是由于需求的不确定性和需求的频繁变更所导致的。而相应的,花费在设计阶段的工作量太少。与需求分析阶段相比,设计阶段的实际工作量明显低于基准参数。如果设计阶段的工作量不够,就会导致软件的设计出现问题,使代码的缺陷增多,继而影响到产品的质量和整个项目的进度。
2)根据相应的需求稳定度、工作量分布率以及缺陷分布率可知,虽然针对系统需求的工作量分布比相应的基准多了20%,但也因此换来了更好的需求稳定性,而且与需求分析相关的缺陷分布率也相对较低,所以,该项目中在需求分析阶段的软件过程质量是很高的。
3)评审过程(包括同行评审和代码审查等)的质量及效率并不高。如表3所示,在评审过程中只发现了426个缺陷中的158个,而剩下的268个缺陷是直到最终测试阶段才发现并进行修正的。这样一来,就把原先可以尽早发现的缺陷拖延至了系统测试阶段才加以解决,从而增加了后续测试工作的压力和工作量,并将直接导致项目进度的落后。
针对上述分析结果,可以提出如下建议以改进该项目的软件过程:
1)增加在设计阶段的工作量;
2)加强针对工作产品的评审力度;
3)尽可能多地在早期阶段移除系统中的缺陷,继续坚持并改善单元测试和代码审查的效率。
5 总结
本文给出了一个软件度量过程模型并定义了相关的角色、度量内容、主要活动、有关的支持工具以及实施软件过程度量的一系列方法。还介绍了在过程度量数据的收集、认证和分析活动中的有关目标、任务和相应的方式方法。文章的后半部分介绍了在一个通过CMM3级认证的软件公司中使用本文提出的过程度量方法的实例,从而证明了该方法的灵活性和有效性。该文的研究成果对有效地评估和改善软件过程从而进一步增强组织软件过程的成熟度是很有帮助的。
参考文献
[1]Watts S.Managing the Software Process[M].Addison-Wesley Publishing Co,Reading,Massachusetts,1989.
[2]Mark C Paulk,Charles V Weber.Key Practices of the Capability Maturity Model,SM,Version1.1[R].Technical Report,CMU/SEI-93-TR-025,ESC-TR-93-178,1993.
[3]Florac W A,Carleton A D.Measuring the Software Process:Statistical Process Control for Software Process Improvement[M].Addison Welsley,1999.
[4]Dorling,A.SPICE:Software Improvement and Capability Determination[J].Software Quality Journal,1993,2.
[5]Zhu S Y,Qian L Q,Su W M.Software Engineering Technology Conspectus[M].Publication of Science,2002:117-134.
[6]Basli V R,Caldiera G,Rombach H D.The Goal Question Metric Approach[Z].The encyclopedia of Software engineering,john Wiley,1994.
[7]Jalote P.CMM in Practice:Process for Executing Software Projects at Infosys[M].Addison-Wesley,2000.
[8]Xu Ruzhi,Qian Leqiu.Research on Metricsbased Software Process Control Optimization[J].Journal of Electronics,2003,31(12A):1206-1209.
[9]CMMI-SE/SW Version1.1[S].Copyright2002by Carnegie Mellon University,January11,2002.
软件评审过程度量 篇4
近年来,国内越来越多的企业开始实施CMMI,逐步开始或者已经建立了符合CMMI模型要求的过程体系。CMMI成熟度二级中包含了一个叫做度量与分析(Measurement and Analysis)的过程域,换句话说,无论是根据CMMI成熟度二级还是三级建立组织过程,都必须对软件开发过程进行度量。
实际上,软件度量并不是CMMI创造的新概念,上世纪80年代,DeMillo和Lipton就描述了度量理论与软件度量的关系[1]。之后,与软件度量及模型相关的文章书籍相继出现,越来越多的研究人员及工程实践人员开始关注这个领域的发展。毫无疑问,使用度量对软件开发过程进行管理是提高产品质量的有效手段。
但是,由于国内许多实施CMMI的组织对于软件工程的理解不足,导致了在建立度量目标、度量项以及进行度量分析时过于依赖外部专家,而对于组织的商业目标、度量模型以及如何使用度量数据并不理解,更多是因为“模型需要”而进行度量活动。
本文目的是为正在建立CMMI过程体系或已经建立但希望在度量方面进行改进的组织提供一定的参考。
1 测试过程度量
过程改进的重要目的就是提高软件产品的质量。而软件质量工程的本质就是研究过程(in-process)度量、项目特征以及最终产品质量的关系[2]。提高软件质量的方法有很多种,包括测试(本文的测试包含静态测试——评审检查以及动态测试)以及质量保证(QA)。而实际上国内许多企业对于QA的实践不足,因此本文在这样的背景下,介绍测试过程的相关度量以及分析方法。
关于如何开展度量活动,实际上CMMI模型MA(Measurement and Analysis)过程域的一些特定实践(SP)也提供了相应的参考[3]。这些实践包括:(1)SP1.1——建立度量目标;(2)SP1.2——确定度量项;(3)SP1.4——确定分析程序。
在建立度量项以及分析方法时,组织既可以按照CMMI模型中已定的顺序,也可以循环地开展以上3个实践。
对于软件测试过程的度量项建立,我们可以参考GQM(Goal Question Metric,目标—问题—度量)方法。该方法的假设是组织首先确定组织目标以及项目目标,之后根据目标对过程、产品进行度量,度量数据必须与目标建立追溯关系,最后的度量数据能够反应目标实现的情况[4]。GQM的方法将度量体系分为3个层次:
(1)概念层(目标):更确切地说,这里的目标是指度量目标,可能是组织目标的一部分,也可能是组织目标的分解子目标。度量目标是指进行度量及分析活动的目的,是由于特定的原因,在特定的环境、过程下,根据特定的观点定义对象。
(2)操作层(问题):设定一系列的问题,通过了解目标对象的特征描述特定目标的实现情况。
(3)量化层(度量项):设定一系列的数据对所提出的问题进行量化回答。
如何为软件测试过程设立相应的目标、问题以及度量项就成为了关键。每个目标可以通过识别其三个坐标——对象(Object)、问题(Issue)、观察角度(Viewpoint)以及目的(Purpose)来确定。例如:
对象:集成测试
问题:效率
观察角度:项目经理
目的:提高
因此,我们设立了这样一个目标——提高集成测试的效率。
对象可以是过程或者产品,问题是对象的一个属性,而对于观察角度,由于选取的度量目标不可能与组织中的所有人员相关,必须在建立度量目标时,识别该过程或产品的相关人。
确定了度量目标之后,需要根据目标提出问题。这些问题可以是关于目标如何实现的或者是目标实现带来的结果[5]。例如对于上文提到的目标,可以提出以下几个问题:
(1)集成测试周期持续时间多长?
(2)集成测试阶段的缺陷移除率如何?
(3)集成测试阶段没有发现的缺陷引起的返工工作量是多少?
制定了符合目标要求的问题后,需要识别相应的度量,这些度量应该能够表现目标是否被实现,也可以认为是对于之前识别问题的量化回答。
对于度量的选择,可能来源于客观的数据,也有可能来源于主观的数据。例如,对于缺陷移除率的度量,由于对象明确,数据获取也不困难,使用客观的统计数据有助于明确地回答“问题”。而对于某些度量,例如客户满意度,由于缺少公认有效的理论模型或操作难度大,一些组织对于该度量的设定更多考虑的是客户对于产品的主观印象。
测试过程相关度量项需要根据组织的特点及需要进行选择。例如组织希望了解软件开发生命周期的薄弱点加以改进,那么可以收集所有缺陷,并对其引入阶段进行分析,统计开发过程各阶段的缺陷引入情况,并通过一定的分析确定改进机会。这些缺陷包括了评审发现的缺陷,单元测试、集成测试等内部测试发现的缺陷,以及验收测试和维护阶段发现的缺陷。
2 测试度量数据分析方法
度量的目的并不是收集数据,更重要的是通过对数据的分析了解过程、项目以及最终产品的状况,找到问题及改进机会。本小节介绍与测试度量相关的分析方法。
2.1 缺陷到达模式(Defect Arrival Pattern)
很多组织都会度量软件的缺陷率,希望能够通过该数据了解软件产品的质量以及可靠程度。各组织对缺陷个数的定义可能并不一致,有的组织仅收集发布前的遗留缺陷,有的组织还收集产品试运行阶段所发现的缺陷。但是实际开发的经验表明,交付前缺陷率相近的产品,其交付后所表现的质量可能完全不同。也就是说,在决定一个产品是否能够发布的时候,除了软件缺陷率,我们还需要其他的信息用以决策。缺陷到达模式就是其中一个可供使用的工具。
每个组织的开发模型可能类似于瀑布模型,也可能采用迭代开发模型,无论是哪一种方式,测试活动都会持续一定的时间。在整个测试过程中,可以记录各个测试时间段或者各次迭代测试发现缺陷的总数,之后描绘出类似于图1的图(X轴代表时间/次数,Y轴代表测试发现的缺陷数)。
图1记录了发布前缺陷率接近的两种软件产品的测试状况,然而两种产品的可靠程度截然不同。图1(a)展示的测试状况说明了该产品在早期就投入了大量测试工作,在产品发布前,缺陷数已经收敛;而图1(b)则说明该产品测试不足,这个时候进行产品发布会有较大的质量风险。软件开发中有一个基本的概念:越早发现缺陷,修复缺陷付出的代价越小。项目组通过对曲线的特征判断各阶段测试活动的充分性。需要指出,曲线的形态与模块的设计以及集成的顺序有关。
另外,测试是一个无止尽的活动,测试什么时候能够结束,产品什么时候才能发布也可能困扰着项目组。既然零缺陷发布的情况很少,我们只能选择产品缺陷率稳定在一个相对较低的水平后再进行发布。缺陷到达模式就能够给予我们一定的参考信息。
如果将测试的范畴扩大到技术评审,统计从需求开发、设计、编码到测试发现的缺陷率,X轴按照软件开发的阶段进行区域划分,那么可以得到各阶段的缺陷到达模式。从图中我们可以判断哪些阶段评审投入时间或效率不足,这种信息既能帮助项目作出及时的调整,也能帮助组织识别改进机会。
2.2 缺陷移除率(Defect Removal Effectiveness)
上文提到使用基于开发阶段的缺陷到达模式统计各阶段验证活动的投入是否充足,然而在计算效率时不能忽略另外一个参数——缺陷注入数。缺陷移除率就是用于表现阶段缺陷发现数以及缺陷注入数的关系。
缺陷移除率有不同的定义。以下列举出几种:
(1)Fagan(1976)定义为:
通过检查发现的缺陷数/检查前存在产品中的缺陷数*100%
(2)Jones(1986)定义为:
发现的缺陷数/(发现的缺陷数+之后发现的缺陷数)*100%
(3)Dunn(1987)定义为:
本阶段发现的缺陷数/(本阶段发现的缺陷数+后面阶段发现的缺陷数)*100%
Fagan的定义与Jones的较为类似,而Dunn的定义则与前者有细微差别。以表1数据为例:
根据Fagan及Jones的定义,集成测试阶段的缺陷移除率:
DRE=集成测试阶段发现的缺陷数/集成测试阶段存在的缺陷数=91/(50+77+97+2-7-22-60)=66%
根据Dunn的定义,集成测试阶段的缺陷移除率:
DRE=集成阶段发现的缺陷数/(集成测试阶段发现的缺陷数+系统测试阶段发现的缺陷数)=91/(91+49)=65%
可见Fagan与Jones的定义关注于某一阶段发现的缺陷数与该阶段存在缺陷数的比例,而Dunn的定义则关注本阶段发现的缺陷数与之后各阶段发现缺陷数的比例。无论使用何种定义,不难发现,缺陷移除率的度量具有滞后性,即某一阶段的缺陷移除率必须等到项目结束或者较晚才能得到,但是对于开发者而言同样具有意义。根据缺陷移除率的度量,开发者能够掌握开发过程中验证活动在各阶段的效率,能够有针对地改进验证过程,尽早地遏制缺陷的扩大。其次,通过对以往类似项目度量数据的比对,开发者能够合理地推测各阶段缺陷移除率的水平,从而预测软件产品的缺陷分布,并且制定相应的质量保证计划,既能够有效地提高软件产品的质量,又能够合理地分配资源,避免漫无目的地测试。
3 结束语
数据的收集及分析都需要花费时间和成本,而小规模企业往往考虑使用最少的资源实现度量实践,却忽略了度量的真正意义。缺少有效的需求调研及良好的设计开发,表面上看似缩短了交付周期,但是实际返工带来的投入往往是巨大而且不可控的。缺陷移除率能够帮助管理者发现开发过程的不足,以制定符合企业特点的调整策略。而对于缺陷到达模式的使用,小规模团队可以在测试的最后阶段使用,并且对关键缺陷进行统计,通过对缺陷检出趋势的观察来判断软件是否到达稳定状态足以发布。紧密地将组织目标与度量实践联系在一起,才能使度量真正地支持开发管理活动,获得更大的投资回报。
摘要：描述度量在测试过程中的使用方法。首先介绍了GQM的方法,并介绍了GQM方法针对测试度量的应用。之后对于数据如何使用及分析,介绍了两种分析方法:缺陷到达模式以及缺陷移除率,并比较了两种对于缺陷移除率计算方法的异同点。最后,针对小型企业如何进行测试度量,提出了建议。
关键词：软件开发,CMMI,GQM,度量,测试
参考文献
[1]Norman Fenton.Software Measurement:A Necessary Scientific Ba-sis[J].IEEE Transaction on Software Engineering,1994(3).
[2]Stephen H.Kan.Metrics and Models in Software Quality Engineer-ing,Second Edition[M].US:Pearson Education,1995.
[3]Victor R.Basili,Gianluigi Caldiera,H.Dieter Rombach.The Goal Question Metric Approach[M].Encyclopedia of Software engineer-ing,1994.