软件产品度量范文

软件产品度量范文（精选9篇）

软件产品度量 第1篇

1基于WebApp设计的软件度量

基于WebApp设计的软件度量我们需要定量地解决以下问题:用户接口是否提高了可用性;WebAPP的美学设计对于应用领域是否合适,是否能够得到客户的认可;是否能够以最小的工作量提供最多的信息的方式来设计内容;WebAPP体系结构设计是否适应WebAPP用户的特定目标和目的、内容结构和功能结构以及有效地使用系统所需的导航流程;构件设计是否减少了流程复杂度且提高了正确性、 可靠性和性能;

解决这些问题,提供量化答案的有效度量集,定性地处理,我们从这几个方面考虑。

本质上,美学设计依赖于定性的判断,通常不遵守测量和度量的规则。所以关于美学度量我们总结一组可能在评估中有影响的测量度集。

该类度量强调内容复杂度和内容对象的聚集。

该类度量处理导航流程的复杂度,通常它们只应用于静态的Web应用,不包含动态产生的链接和页面。

2源代码度量

Halstead提出利用可以在代码生成后导出的或一旦设计完成之后可以估算得到的一组基本测度,源代码度量的一组基本测度如下:

n1= 在程序中出现的不同操作符的数量

n2= 在程序中出现的不同操作数的数量

N1= 出现的操作符总数

N2= 出现的操作数总数

我们利用这些基本测度形成一些表达式,这些表达式可用于度量整个程序的长度、算法的最小潜在信息量、实际信息量(指定一个程序所需的“位”数)、程序层次(一种软件复杂性测度)、语言级别(对给定语言为一常量)和其他特征(如:开发工作量、开发时间、软件预计缺陷)。长度N可以估算如下:N=n1log2n1+n2log2n2,而程序的信息量可以定义为:V=Nlog2(n1+n2), 需要注意的是,V随着编程语言的不同而不同,它表示说明一个程序所需要的信息量(以“位”计数)。

理论上,一个特定算法必定存在一个最小信息量。信息量比率L定义为程序最简洁形式的信息量与实际程序的信息量之比。实际上,L一定总是小于1的。基本测度信息量比率可以表示为:L=2/n1*n2/ N2。

3测试度量

体系结构设计度量提供了与集成测试相关的难易信息以及对专用测试软件的需求。环复杂度(一种构件级设计度量) 是基本路径测试的核心。此外,环复杂度还可以用来定位要进行广泛单元测试的候选模块。环复杂度高的模块可能比环复杂度低的模块更易于出错。因此,测试人员还应该在将这些模块集成到系统之前花费超过平均值的工作量以发现该模块中的错误。

界面度量 :

美学(图形设计)度量

内容度量

导航度量

(1)用于测试的度量,从测试导出的度量也可用来估算测试工作量。利用程序信息量V的定义和程序层次PL,可以计算工作量e :PL=1/[(n1/2)*(N2/n2)],e=V/ PL。分配给模块k的工作量占整体测试工作量的百分比估算:k=e(k)/ ∑ e(i),其中, e(k) 是计算模块k的测试工作量,∑ e(i) 是系统所有模块的工作量总和。

(2)面向对象测试的度量,为设计质量提供了一种指标,它也为检查一个面向对象系统所需要的测试工作量提供了通用的指标。Binder提出过一组对面向对象系统的可测试性具有直接影响的设计度量。这个度量更多的考虑了封装和继承方面。

a方法缺少内聚(lack of cohesion in methods, LCOM)LCOM的值越高,为保证方法不会产生副作用,需要测试的状态越多。

b公有与保护属性的百分比(percent public and protected, PAP)。公有属性是从其他类继承的,因此对这些类是可见的。 保护属性对子类的方法是可访问的。该度量指明类的公有属性或保护属性的百分比。PAP的高值增加了类间副作用的可能性,由于公有和保护属性导致较高的潜在耦合。必须设计保证发现这些副作用的测试。

c对数据成员的公有访问(public access to data members, PAD)。这个度量指明可以访问另一个类属性的类(或方法) 的数量,这违背了封装。PAD的高值导致类间的潜在副作用,必须设计保证发现这些副作用的测试。

d根类的数量(number of root classes,NOR)。该度量是在设计模型中描述的不同层次的计数。必须为每个根类和相应的类层次开发一组测试。当NOR增大时,测试的工作量也随之增加。

e扇入( fan-in, FIN)。当用于面向对象环境时,在继承层次中的扇入是多继承的指示。FIN > 1指示类从多个根类中继承属性和操作。应该尽可能避免FIN > 1的情况。

软件产品度量 第2篇

作为一名默默奉献的教育工作者，时常需要用到教学设计，借助教学设计可以更好地组织教学活动。一份好的教学设计是什么样子的呢？以下是小编整理的角的度量教案 《角的度量》教学设计，仅供参考，大家一起来看看吧。

角的度量教案 《角的度量》教学设计1

教学内容：

课本P83-85

教学目标：

知识与技能：

1、知道角的计量单位“度”。

2、认识量角器，初步会用量角器量出角的大小。

过程与方法：

通过解决实际问题的过程，认识量角器的结构与功能；通过实践操作，归纳量角器量角的一般步骤。

情感态度和价值观：

体会统一计量单位和度量工具的必要性，感受数学的简洁严谨。教学重点：会用量角器量出角的大小。教学难点：会正确使用量角器量角。

教学过程：

一、复习引入

1、复习角的组成，并画角，同桌比一比谁的角大。

2、比较角的大小要先知道什么？怎样量出角的大小？今天我们就一起来探讨这类问题的解决办法。（出示课题：角的度量）

二、探究新知

（一）认识角的计量单位

1、师：角的计量单位是什么？

2、课件演示：介绍角的计量单位

3、师：你知道这个角有多大了吗？有这样的几个1°，就是几度。

4、（出示70°角）这个角几度？

（二）认识量角器

1、用1°角拼成半圆，一共有几度？你怎么知道的？它们共同的顶点在哪里？

2、把量角器进行美化，读角的度数（52°、131°）

3、（出示30°开口朝左的角）师：那这个角几度？你是怎么看的？为了方便我们量各种方向角，我们可以从左边顺时针再标数据，这样就形成了度量角工具：量角器。

4、看书P83，对应着自己的量角器去找一找量角器上有什么，再和你的同桌说一说。

5、读角的度数，用手势表示。（开口朝右80°、155°、开口朝左55°）看哪圈刻度？怎么判断？

6、小结：量角器上有两圈刻度，我们怎么判断到底读哪圈的刻度？

（三）用量角器量角

1、学生尝试量角。讨论总结量角的方法：

2、中心点与顶点重合

3、零刻度线与边重合

4、读刻度

三、巩固与提高

1、量∠4=40°，有什么不一样的.方法？两种方法有何不同？

2、量∠5=120°同桌合作，互相检查。

3、量钟面上时针和分针组成的角。

4、量自己画的角，并与同桌的角比一比。

五、总结

1、今天我们学习了什么？

2、书上有一种特殊的量角器，看看它和你们的量角器有什么不同？这把量角器有什么特殊的作用呢？课后探究一下。

角的度量教案 《角的度量》教学设计2

一、教学内容：

角的度量教材第26~28页

二、教学目标

1、认识量角器、角的度量单位，会在量角器上找出大小不同的角，并知道它的度数，会用量角器量角。

2、通过一些操作活动，培养学生的动手操作能力。并通过联系生活，使学生理解量角的意义。

3、通过观察、操作学习活动，形成度量角的技能，同时使学生经历和体验知识的形成过程。

4、在学习过程中，感受数学与生活密切联系，激发学生学习数学的兴趣。

三、教学重点难点：

1、引导学生观察量角器，认识内刻度线、外刻度线、0刻度线和中心点。知道角的计数单位“度”及相关知识。

2、掌握用量角器测量角的方法，能正确测量各种角的度数。

四、教具准备：

量角器、三角板。

五、过程：

（一）导入

教师：昨天我们根据角的边张开的大小认识了几种角，你们还记得吗？

学生说后，请他们按从大到小的顺序排列，即：周角、平角、钝角、直角、锐角。

我们已经认识了角，角的大小和什么有关系呢？大家会比较角的大小吗？

教师出示两个大小相近的角，问同学：∠a和∠b谁大谁小呢？ 学生自由发言。

教师：∠a和∠b究竟谁大呢?那大多少呢？大一点？这一点又代表多少呢？今天我们就来学习角的度量，相信学过这节课后，你就能解答这个问题了。板书课题：角的度量

设计意图：通过以问题的形式引出量角器的必要性，培养学生善于思考，发现问题的能力，在自主探究中学习。

（二）探究新知

1、认识量角器

教师：为了使测量更准确，描述更清楚，就产生了标准的测量角的工具——量角器。（板书：量角器）

出示一个量角器。教师边说边演示：人们将圆平均分成360份，把其中的1份所对的角叫做1度，记作1°，通常用1°作为度量角的单位。板书：度1°

提问：你知道一个周角是多少度吗？（360度）

一个平角是多少度呢？（180度）

介绍：度量角的大小，可以用量角器，它把半圆平均分成180份。

2、认识量角器的中心、0刻度线、内外圈刻度。（1）指导

请大家仔细观察自己的量角器，认真地研究研究，看看你有什么发现。

（2）小组合作研究量角器。

（3）学生汇报研究的结果。注意这里要尽量让学生说出自己的想法，有的问题还可以让学生来解答。

教师根据学生的回答，要说明哪里是量角器的中心，哪里是0度刻度线及内刻度和外刻度，量角器是把半圆平均分成180份等。根据回答作出下列板书：中心、0度刻度线、内刻度和外刻度。

小结：量角器上有中心、0度刻度线、内刻度线和外刻度线。

3、量一量。

教师：我们了解了量角器上有什么，究竟怎么使用它呢？接下来让我们一起来研究研究。

（1）尝试量角，探求量角的方法。

出示教材第27页“试一试”，写出∠a和∠b的度数再读一读。教师：通过观察以上两组角，我们会读角的度数了，那该怎样量角呢？请你与同学交流量角的方法。

学生交流完之后，请两位学生到前面演示说明。

通过学生的演示度量，老师组织学生总结用量角器量角的方法，指导学生实际操作，按步骤去量角。

第一步，使量角器的中心点与角的顶点重合；

第二步，使量角器的零刻度线与角一条边重合； 第三步，看角的另一条边所对量角器上的刻度，就是这个角的度数 教师：我们可以把这三句话概括为四个字“两合一看”。“两合”是指中心点与角的顶点重合；0刻度线与角的一边重合。“一看”就是要看角的另一边所对的量角器上的刻度。（板书：两合一看）（2）突破读内圈刻度，还是读外圈刻度的难点。提问:量角器上为什么有内外两圈刻度呢？ 教师引导学生带着疑问研究。出示130°和50°的两个角 教师：左边这个角的度数是多少？

是130°还是50°？读内圈刻度，还是读外刻度线上的数？ 学生明确：这个角的度数是130°，要读外刻度线上的数。教师：右边这个角应该看内刻度，还是外刻度？是多少度？ 学生：这个角是50°，应该看内刻度。

质疑：为什么左右两个角看的刻度线不一样呢？什么时候看内刻度？什么时候看外刻度呢？ 学生小组交流。

学生可能会想到以下几种情况

学生甲：我们小组认为，在读度数之前应该先判断这个角是钝角还是锐角，如果是钝角肯定大于90°，是锐角要小于90°，然后再找刻度就不会错了。

学生乙：我们小组认为，要先找0刻度线，如果一条边压住的是外圈的0刻度线，那么肯定读外圈刻度。反过来压住的是内圈刻度的0刻度线，就要读内圈刻度。……

教师：这几个组的方法听起来都挺有道理，我们不妨试一试哪种方法更好。

（3）学生练习量角，巩固新知。小结量角的方法——两合一看 提问：看角的度数时要注意什么？

学生：要注意是看外刻度线还是看内刻度线。问：什么时候看外刻度线，什么时候看内刻度线呢？

小结：找0刻度线，如果一条边压住的是外圈的0刻度线，那么肯定读外圈刻度。反过来压住的是内圈刻度的0刻度线，就要读内圈刻度。设计意图：学生先独立练习，再交流订正，使学生能在练习中进一步将知识内化，并相互帮助提高。通过游戏活动，让学生自主测量角，培养学生学数学、用数学的意识。

（三）课堂作业设计

1、教材第28页第1题。

学生在找出正确答案后，应该说一说是怎样想的。

2、教材第28页第2题。∠1的方向是朝下，可以让学生先说一说量角的方法，然后再进行度量。

（四）课堂小结

今天我们学习了什么内容？你有什么收获？

软件产品度量 第3篇

关键词：CMMI；软件测试过程；度量分析

中图分类号：TP311.52

近几年来，随着我国信息技术的迅猛发展，软件行业得到大幅度提高，使得软件项目的功能等复杂度在逐步壮大，与此同时，软件的成本和质量也很难得到控制。那么，如何提高软件产品的质量成为当前软件行业普遍关注的问题。而软件度量分析是改进软件过程中的关键所在，最终为软件过程提供量化测试结果。因此，基于CMMI的软件测试过程度量分析的研究，对提高软件产品的质量具有重要的实际意义。

1 CMMI软件测试和度量之间的关系

1.1 CMMI和软件测试

CMMI的提出的目的是为了提高软件产品的质量，有利于改进软件过程，可以说，CMMI是一个广泛使用的过程改进模型。由于在软件过程中，软件测试是其中关键性内容，基于CMMI的软件测试能够为软件过程的改进提供重要的指导性方针。尤其在CMMI连续表示中，软件测试和验证域和过程域紧密相连，对改进软件测试过程提供了重要支持。其中，常见的过程域有风险分析过程、量化项目管理过程等。

1.2 CMMI和度量

CMMI为软件开发提供了重要度量和分析过程域，有效提高了管理信息所需要的度量能力。通常情况下，度量能够提取软件过程或产品的表征数据，而分析则主要对数据进行分析，一旦发现不一致及其他问题，为及时采取措施进行处理，促使软件企业免受损失。度量分析执行流程如图1所示。从中可以发现，CMMI的度量分析流程主要由计划、收集和分析这三部分构成。对于计划过程来说，它主要是确定并细化度量目标。对于收集过程来说，它主要是采集并存储数据，进而实现对数据的收集和检查过程。而分析过程主要是按照相应分析原则对数据进行分析和存储，甚至还能够报告结果的过程。所以，CMMI的度量分析过程比较严格，但具有明确的目标，流程十分清楚，实现对软件测试过程的指导和度量活动。

图1 度量和分析执行流程

2 软件测试过程模型

2.1 软件测试阶段划分

在软件投入运行之前需要对软件进行测试，软件测试目的就是确认软件需求和设计说明以及编码的是否合理。因此，软件测试直接影响着软件的生存周期。通常情况下，软件程序中的故障不一定由代码错误引起，还可以能是详细设计过程、需求分析阶段等出现问题造成，总之，软件问题可以存在于软件开发的整个环节。基于此，这就要求软件测试贯穿于软件定义和开发的整个阶段，其中包括单元测试、集成测试、确认测试等各个阶段。对于单元测试来说，它是软件开发过程中最低级别的测试活动，和传统的C语言相比，其单元测试的对象一般是函数。但在类似C++语言中，其单元测试的对象还可以能是类或类的成员函数。对于集成测试而言，当每个模块能够单独工作之后，将这些模块组装在一起，同时还要验证其是否正常，一旦出现问题，将会给影响功能的发挥。当每个模块进行单元测试完毕之后，则需要按照相应的设计结构程序图进行组装，为集成测试提供重要依据。当各个单元测试中的各个模块组合在一起之后，利用集成测试就可以对接口相关的不同故障进行检测。对于确认测试来说，当在完成集成测试之后，可以连接分散开发的模块，从而构成一个完整的程序，待各个模块之间的故障消除之后，就可以直接进行确认测试。在确认测试过程中，主要按照软件需求说明书作为主要依据，评估软件产品的质量等，从而满足软件需求过程，并及时对软件功能、接口等方面做出严格评价。

2.2 基于CMMI的软件测试过程模型

基于CMMI的软件测试过程需要遵循多个原则，第一，软件测试应贯穿于整个软件生命周期中；第二，软件测试需要具有严格的过程定义，同时还要严格按照相应的规范进行输入、输出和过程本身，且每一个测试阶段都有多种任务；第三，软件测试过程中拥有不同的测试对象，为不同开发阶段提供不同类型的测试；第四，软件测试应及时进行，一旦满足测试环境就可以实行软件测试过程；第五，软件测试除了和软件开发周期息息相关，还和风险管理以及成本管理等有着直接联系。第六，软件测试活动应将确认和验证作为重点。软件测试过程模型左边从需求分析开始直至软件运行和维护都需要测试，进而将测试需求递交至右边的软件测试基本流程中。在这个过程中，测试计划、测试设计等每个阶段都有一系列的任务，而这些任务均和整个测试流程有着密切联系，比如，在测试计划中，它主要以测试需求为依据，计划测试包括单元测试和集成测试等。

3 度量元的选取和细化

3.1 度量元的选取模型

基于CMMI软件测试过程为软件开发提供更多的实践指导，因此，根据CMMI的要求和原则，引入度量分析是十分必要的。而利用GOM方法能够有效确保度量元选取以及细化的有效性。由于GOM有效利用了目标驱动，使得软件开发具有较高的效率。也就是说在利用GOM方法时，要先对一组目标进行确定，然后针对各个目标提出极有可能出现的问题，这便是对目标的定义，待定义完目标之后，应针对每一个问题设计出相应的测量方法，这样就可以用这一组的测量方法所得出的度量元解决这一问题。在这个过程中，利用GOM方法最主要的是确保问题转化的完整性和匹配性。

3.2 度量元的选取原则

度量元的选取原则具有多种，其中有过程域裁剪原则、实践剪裁性原则、文档剪裁性原则等，对于过程域裁剪原则来说，每个STPA均有几个相关过程域，如果几个STPA同时拥有一个确定的过程域，那么就应该实行保留并合并下来，如果涉及软件测试关系性不强，那么则可以完全删除，如此一来就可以确保软件测试实践的有效性和完整性。对于实践剪裁来说，基于CMMI的整个软件过程改进中，需要对整个软件过程的实践性进行及时关注，尤其是置换软件测试过程。通常情况下，如何和软件测试无关的某些实践，都可以直接剪裁掉。如果针对某些零散的实践，如果表示的同一目标，那么可以直接进行合并。对于文档剪裁性原则来说。通常情况下，每个STPA均拥有大量且繁琐的文档，这给管理和维护带来一定困难。针对此，应保留和测试输入或输出相关的文档资料，为整个度量分析提供重要依据。

4 结束语

综上所述，基于CMMI的软件测试过程度量分析是软件行业中重点内容，尤其是近几年来，我国软件行业得到大幅度发展，使得软件成本和质量出现失控的状态，针对此，基于CMMI的软件测试过程度量分析有效改善了这一问题。因此，文中基于CMMI的軟件测试过程度量分析进行探讨，不仅为度量分析的应用起到了良好的指导作用，还具有一定辅助作用。相信，在未来，CMMI的软件测试过程度量分析将会更加完善，进一步推动软件行业的稳健发展。

参考文献：

[1]张少岗.基于CMMI的软件过程度量研究与应用[D].郑州大学，2010：5-10.

[2]方炯华.基于CMMI的软件度量模型研究与应用[D].厦门大学，2011：26-28.

[3]万邦睿，丁晓明.基于CMMI的软件测试过程度量研究[D].计算机工程与设计，2007（11）：2530-2546.

作者简介：包玮琛（1984-），男，蒙古族，辽宁大连人，讲师，硕士，研究方向：软件工程。

软件产品度量 第4篇

1.1 简述进度度量

就当前的科学技术来说, 世界上人们在实际工作过程中所使用的进度度量方法主要包括两个大方面:一是, 非常简单容易进行的, 例如时间计划、跟踪项目预算等, 虽然操作简单, 但是在一个任务上所花费的时间和金钱不能非常准确的反映出实际中被执行的工作情况, 而且项目的进展程度, 也不能只依靠时间表和花费情况来进行测量;二是, 操作起来非常简单的, 例如基于WBS工作分解单元和里程碑等方法。然而该方法也存在以下几个方面的不足:

(1) 基于成果的基础上才划分的里程碑, 但是当项目进程需要通过周期来进行划分时, 该方法就不能准确的提供。

(2) 估算是进度度量的基础, 在WBS工作分解单元中的工作量是评价个人经验的基础上进行的估计, 而且进度度量是否可靠也不能仅仅凭借估算就能够直接确定。

1.2 进度计算

当前人们主要是用“落后预计X天”或者是“提前预计X天”来作为进度的单位, 然而这种进度计算方法并不能把完成项目的比例准确的反映出来。因此, 人们为了更好地反映出项目的完成比例情况, 可以在设定进度标准时将完成比率来作为, 同时还要将变动工作量以及由于问题而引发的工作量对项目进程情况的影响充分考虑进去, 从而能够更加实际的反映出项目计算的进度情况。

以用例为单位来对项目进度进行相应的计算, 因此, 项目进度P由公式 (1) 所表示:

在公式 (1) 中, 第i个用例完成的程度情况用来Ci表示, Ci用公式 (2) 来表示:

在公式 (2) 中, 第i个用例已经完成的有效工作量用来t'i表示;第i个用例的总工作量用ti来表示。ti由公式 (3) 所示, 由此可以看出, 该公式中包括了由于问题而引发的工作量和临时改变而引发的工作量这两部分。在此我们假定第i个用例问题有n个, 而临时改变有m个那么最终表示为:

1.3 临时需求改变和问题引发的工作量计算

对临时需求改变而引发的工作量进行相应的计算, 能够将需求稳定程度准确的反映出来。由公式 (4) 所示:

在公式 (4) 中, 项目新增加的需求工作量用Cr来表示;第i个用例改变后的规模用U'i来表示;第i个用例的第i个临时需要而引起的改变的工作量用UCil来表示。

2 进度分析

进度信息在被分析模型处理后, 在跟它格式相同的基线数据进行做对比, 从而有利于准确的发现项目中还存在的问题, 这样将会非常有利于项目管理人员更好、更具有真对性的控制项目进度。

当前人们在对软件开发过程中, 基本上只有一种分析进度的方法, 这种方法只能够大概的判断出项目整体上的进度, 而不能准确的分析出对进度的影响因素。因此人们在设计进度评价指示器体系时, 充分考虑到项目的不同, 人的信息需要提供各种级别的进度信息, 另外在进度评价指示器中的分析进度偏差方面主要暴力以下三个方面:错误工作指数、需求变动指数以及单个员工进度偏差。为了更好地分析指标, 我们将指标设计成了以下三种级别的结构:面向公司执行官级别、面向部门经理级别和面向项目经理级别。另外, 根据进度需求类型的不同, 将指示器分为以下两种:一是, 进度偏差类型, 该类型的指示器主要是通过采集数据相减计划数据最终得到的;二是, 需求稳定指数类型, 该类型的指示器主要是通过工作量比率方式得出的。因此, 以上两种类型的指示器能够充分满足实际工作中的各种需求。

3 结论

当前人们在项目进度偏差计算方面还存在着一些问题, 因此, 本文提出了新的进度度量方法, 这对准确的分析进度偏差、错误工作指数、需求变动指数等方面的偏差影响因素起着非常重要的促进作用。

参考文献

[1]何宜军.基于过程模式的软件过程度量模型研究与应用[D].湖南大学, 2013.

[2]王超男.Internet环境下高可信网构软件度量技术的若干问题研究[D].浙江师范大学:计算机软件与理论, 2010.

基于度量的软件缺陷管理研究 第5篇

软件度量最初是用一些方法来量化软件以及软件开发过程,从而有效地管理软件过程,在尽可能节约资源的情况下提高软件开发效率。现在,度量已经成为一项基本的软件工程实践,并且随着人们对软件度量认识的逐步深入,度量在软件开发中应用的广度和深度也以前所未有的速度发展。作为软件项目管理中的重要环节,目前其缺陷管理模式依然是找出缺陷、修改缺陷、进行回归测试的传统模式。本文针对传统的缺陷管理模式的不足,在其管理过程中引入软件度量的方法,对缺陷管理过程进行度量、分析,发现现有缺陷管理过程的不足,给出相应的改过措施,提出一个在软件企业可行的缺陷管理过程。并且通过企业的反馈得到了较好的效果。

一、缺陷管理过程

(一)缺陷数据收集

针对某软件公司的八个项目的跟踪,通过对公司质量管理部门的项目质量数据表的整理:将八个项目在各阶段发现的缺陷数据进行整理汇总,同时将各阶段的超期问题数汇总,得到表1

(二)缺陷数据分析

从表1中的数据我们可以看出:

项目P03,在编码阶段的缺陷数为2100多,在测试阶段缺陷数接近2500,而在试运行阶段的缺陷数超过了2500个,在整个项目周期中缺陷数达到了最大值。同时,我们看项目P01、P02、P03缺陷分布,都是在试运行时发现的最多,从表1,可以看出每个项目,在整个项目开发周期中,所发现的缺陷数都较多,而且在每个阶段都有较多的超期没有解决的问题。究其原因,主要是缺陷管理过程不规范,致使很多问题超期不能解决;测试力度不够,本应在编码和测试阶段发现较多的问题,确在试运行阶段发现最多的缺陷。缺陷跟踪力度不够,致使同一类缺陷在不同阶段重复出现。对于这八个项目所呈现缺陷分布曲线趋势大致相同,这说明,在一个项目中存在的问题,在其他项目中也同样出现,缺陷的度量分析不够。

(三)缺陷管理过程改进措施

1. 原缺陷管理过程

从对缺陷数据的采集,分析数据,我们发现,公司原有的缺陷管理过程存在着一些问题。缺陷管理一直采用“找出缺陷、修改缺陷、进行回归测试”传统被动模式,而没有很好地将缺陷管理的反馈信息应用到软件过程中来,以达到软件过程改进的目的。缺陷管理只是针对某一个特定项目而言,而不是针对一个项目开发团队而言。缺陷的处理往往是为了保证当前软件产品的交付而做的,而没能将当前项目中的一些缺陷管理信息形成一种团队共享知识,以防止其他项目中犯类似的错误。

2. 缺陷管理过程改进措施

针对原有缺陷管理存在的局限性,为了有效地减少软件产品的缺陷数,规范缺陷管理过程,达到应用缺陷管理来改进软件过程的目的。

我们提出了缺陷管理过程提出了改进措施,给出了一个实用的缺陷管理过程。

(四)缺陷管理过程:

我们给出了一个标准的缺陷管理过程如图1,为发更好的跟踪记录缺陷记录,设计了《缺陷跟踪与记录表》,

识别缺陷:

缺陷识别贯穿在开发管理活动中,包括同行评审(走查)、测试、验收、上线运行后的用户反馈等。测试人员、评审人员、走查人员、验收人员等负责缺陷的识别,包括缺陷编号、描述缺陷、对缺陷进行分类、确定缺陷的严重级、缺陷状态、发现方式。缺陷识别的结果应全部纳入统一的记录表格或记录工具中,防止遗漏缺陷。

处理缺陷:

项目经理确定缺陷的优先级、落实责任人、预估工作量、确定改错完成日期,并下达改错任务。缺陷的责任人负责按优先级顺序处理缺陷,拒绝修改和修改缺陷是处理缺陷的两种措施。拒绝修改应说明原因,如“不是缺陷”、“暂不修改,在升级版本中解决”等,并将缺陷状态置为“已拒绝”。拒绝修改必须获得审批,严重级为“一般”、“建议”的缺陷拒绝修改由项目经理批准,严重级为“致命”、“严重”的缺陷拒绝修改由部门经理或高层经理批准。审批通过将缺陷状态置为“已关闭”,审批未通过的将缺陷状态置为“未修改”。当“未解决”的缺陷数累计超过20个时,相关责任人必须立即停止新的开发工作,首先着手解决缺陷,并将已解决的缺陷状态置为“已解决”。缺陷的识别人对“已解决”和“已拒绝”的缺陷进行验证,包括审核、再测试或评审,验证通过将缺陷状态置为“已关闭”,验证未通过将缺陷状态置为“未修改”。缺陷处理的结果应全部纳入统一的记录表格或记录工具中,方便缺陷跟踪。

记录缺陷：

应在统一的记录工具中记录缺陷识别和缺陷处理的结果,缺陷记录要求:为测试和同行评审中发现的每一个缺陷做一个记录;对每个缺陷要记录足够详细的信息,以便以后能更好地了解这个缺陷。

二、改进后的结果

我们将缺陷管理过程改进措施在某软件公司使用,从公司质量管理部门进期的检查中发现,在各阶段的缺陷数有较大下降,由于对缺陷进行严格的跟踪,所以大大减少了超期未解决的缺陷数。而且取得了一定的实际效果。H

参考文献

[1]Sami Zahran..软件过程改进[M].陈新译.北京:中信出版社,2002.

[2]何新贵,王纬,王方德,等编著.软件能力成熟度模型[M].北京:清华大学出版社,2000.

[3]张瑞.基于度量的软件缺陷管理研究[D].西北大学,2005.

软件产品度量 第6篇

目前信息安全领域研究的热点问题之一。计算机系统是否可信, 包括硬件、网络、操作系统、中间件、应用软件、信息系统使用者以及它们之间的交互的复杂系统等是否可信, 在这条链上的任何一个环节出现问题, 都会导致计算机系统的不可信。

目前国内外可信计算的研究主要集中在硬件层面。软件可信性研究是可信计算的一个分支。对于越来越复杂的各种应用软件, 软件内部存在危机、缺陷、错误、故障、失效, 软件外部存在病毒、恶意代码入侵, 如何进行可信性的评估, 特别是量化的可信性评估是一个值得高度重视的问题。可信性是比任何其它特征都具有综合性的一个性质。本文以软件工程为背景、信息安全领域知识为依托, 在软件可信性定量化研究方面进行了探索。

1 软件可信树度量方法研究

模糊现象在软件工程领域中很常见, 如规模是大是小、软件质量是好是坏等, 都没有明确的边界, 呈现出模糊性, 软件是否可信也是如此。由于对软件可信因子对应的指标进行评价涉及到了评审专家的主观认识, 具有模糊性, 因而无法用常规的精确逻辑来描述和处理。所以, 在可信因子评价的研究中需要寻找一种既能反映可信因子评价的模糊性, 又具有直观、简洁语义的定量描述机制。本文将模糊理论引入到软件可信因子评价的研究中, 以解决对具有模糊性的软件可信性因子评价进行建模的问题。由于因子太多、层次复杂, 本文借鉴经济学和管理学中常用的决策树方法, 提出采用类似于决策树的一种树形结构, 即提出了可信树的方法。

本文把传统的可信特征属性进行修正, 提出了一种通用的可信因子定义机制, 而所定义的可信因子的具体内容则可以根据具体的软件来决定。软件可信因子系统是树状结构, 本文称为软件可信因子树, 简称软件可信树。可信树由根节点、中间节点、叶子节点构成, 根结点表示软件可信的信任值;中间结点表示构成软件可信值的中间因子;叶子结点表示构成软件可信值的最小因子。

2 软件可信树结构分析

软件可信性是描述软件能提交正确服务的性质, 当软件违背了这些性质会造成不可容忍的损失时, 称这些性质为软件可信性。一个应用软件要可信, 必须具备的前提条件是可用、可靠、完整, 否则没有可信而言。软件可信必备性质有:软件可用性 (完成特定任务、达到特定目标) 、可靠性 (规定功能运行可靠、程序运行可靠、环境条件可靠) 、完整性 (数据来源完整、计算程序完整) 。这其中只要有一个性质没有满足, 那么该软件就为不可信, 即是说, 该软件的可信值为-1~0之间, 等级为不可信。

3 软件可信度量评估系统的设计与实现

3.1 软件可信度量评估系统的结构

软件可信计算度量评估系统通过专家对最小可信因子及其权重打分方式获得值来得出评估一个软件可信度量的值及其所属等级。在软件可信树等级化度量评估系统中, 用户类型分为3种类型:系统管理员、软件管理员和软件评估员。软件可信计算等级化度量系统采用Browser/Server体系结构, 将Client端的应用程序模块和现实功能分开, 并将其放到Web服务器上单独组成一层, Client端只需安装单一的浏览器。在服务器端分成Web应用服务器和数据库服务器。软件可信树包括:软件可信树因子的选取、确定软件可信树的体系结构、选取可信树因子的度量方法、构建可信树因子函数、拟出可信树因子的迭代步骤、找出可信树算法等。

3.2 软件可信度量评估系统的UML功能分析

采用用例驱动的分析方法分析需求的主要任务是识别出系统中的参与者和系统用例, 并建立用例模型。需要区分专家评估、系统评估、软件管理等概念。软件管理是由软件管理员对软件进行添加、删除、编辑等;软件评估员对某个或某些软件的最小可信因子和权重进行评估:系统评估是在专家评估员对软件的最小可信因子评估的基础上, 通过一定的算法由系统管理员来自动生成软件可信计算值和软件可信计算等级。

3.2.1 识别参与者

通过对系统需求的分析, 可以确定系统中有5个参与者: (1) System manager (系统管理员) :系统管理员维护系统, 维护软件管理员和软件评估员的注册信息并对其权限进行管理; (2) Software manager (软件管理员) :可以添加、编辑、删除软件信息, 并对软件可信性进行总评估; (3) Software estimator (软件评估员) :软件评估员可以选取软件进行评估、可以对最小可信因子进行评估、可以对最小可信因子占父因子的权重进行评估; (4) Software DB (软件数据库) :对评估的软件进行管理; (5) Expert DB (专家数据库) :对参加软件评估的专家进行管理。

3.2.2 识别用例

通过对需求的进一步分析, 可以确定系统中有以下用例存在:用户登陆 (User Login) 提供了用户使用系统功能的控制;用户注册 (User Register) 提供了用户输入注册信息的功能;系统管理 (System-Manager) 用于系统管理员对系统进行维护;注册管理 (Register Manager) 用例用于系统管理员对软件管理员和软件评估员进行注册信息的维护;权限管理 (Permision manager) 用例用于系统管理员对软件评估员和软件管理员的权限进行管理;软件选取 (Software Select) 用例为软件评估员选取想要评估的软件;因子评估 (factor Evaluation) 用例为软件评估员进行最小可信因子进行评估;权重评估 (Weight Evaluation) 用例为软件评估员对可信因子占其父因子中的权重进行评估;软件信息维护 (Software Info_Maintain) 用例为系统管理员对要评估的软件进行添加、编辑、删除操作;专家选取 (expert Select) 用例用于选取批准评价某个软件的专家。

4 结束语

本文将软件可信度量方法研究的软件可信树等级化度量成果进行了分析, 设计了软件可信计算等级化度量系统来评估软件的可信计算分值和等级。从对系统的分析、系统的结构设计、UML分析与系统设计到系统实现进行了展示。结果软件可信测试的等级为:-1~0, 不可信;0~1, 低可信;1~2, 中可信;2~3, 高可信, 实现了软件可信等级化度量可信。

参考文献

[1]姚文斌, 李炯亮, 汪东升, 等.相异性容错软件故障模型[J].清华大学学报 (自然科学版) , 2005 (4) .

[2]陈火旺.高可信软件工程技术[J].电子学报, 2003 (12) .

[3]余勇.软件安全开发模型的研究[J].计算机安全, 2005 (4) .

基于度量的软件过程改进研究 第7篇

基于此,本文将软件度量深入到每一个具体的软件过程中去,给出基于度量的软件过程改进模型SPIM。确定要实现该软件过程所需采集的度量数据,然后对采集的数据进行分析,量化地了解该软件开发过程的优势和弱点,根据度量结果采取相应的改进措施,从而提高软件开发的质量。

1 基于度量的过程改进模型SPIM

过程度量是实施过程改进的基础。过程改进是利用过程运作所获得的反馈信息,发现当前软件过程存在的问题和缺陷,提出改进的意见,进而实现软件过程的改进和完善。

过程度量与过程运作紧密相关,是一个由多个角色,在一定的条件和约束下,按计划进行的一系列活动。

过程度量的主要活动

软件过程度量的过程由数据获取和度量分析组成,其中数据获取包含数据采集、数据验证两个活动。而度量分析包括数值转换、数据分析和度量决策三个活动。

数据采集,是过程度量的基础,用于收集与所要求的度量值相关的基础数据。合理选取数据来源,开发各种各样的标准化的报表,使用有效的数据收集工具是实现数据获取的重要手段。

数据验证,包括两个方面的活动内容。一方面是检查数据采集的过程是否按计划执行,另一方面要验证每个度量活动的输入和输出是否是正确的、满足要求的。

数值转换,数据获取阶段得到的数据杂乱无章,必须经过加工处理即进行适当的数值转换才能用于度量分析。数值转换的任务是进行数据标度,实现从观察得到的状态到一个数值范围的映射。

数据分析,利用适当的工具和方法,将经过数值转换汇总或计算的度量结果进行比较分析,并发现所度量的过程存在的问题。

度量决策,管理者在清晰地了解到当前过程存在的问题或需要改进的内容后,提出相应的过程改进意见,同时按照一定的决策分析处理(DAR)方法做出下一阶段过程度量的目标和内容,从而引发在新的软件过程周期中实施新的过程度量与改进。

2 模型的应用实例

2.1 需求数据的采集

针对某软件公司的八个项目的跟踪,得到项目的需求数据在不同开发阶段分布记录如表1和表2:

表1和表2是在对这八个项目采集到的数据,经整理得到。

2.2 需求工作过程分析

根据表1和表2中采集的需求分布数据,针对所采集的这八个软件项目的需求工作量分布数据,将其按阶段计算出平均值。

那么,从表中这些数据,我们可以看出:

1)需求工作量与完成情况分布在项目生命周期各阶段,反映了实际的项目状况,但没有一个项目的需求工作计划与此一致。

2)在需求开发阶段,投入了超过40%的需求工作量,所能获得的稳定需求成果不足35%,成效不足。

3)在需求开发之后,投入了51%多的需求工作量,所能获得的稳定需求成果超过59%,时效不足。

4)编码、测试、试运行所获取的需求工作成果超过30%,并且呈递增趋势,说明需求阶段工作质量存在问题,这也是实际的项目状况的客观体现:编码时间长、试运行时间长、迟迟达不到验收要求。

2.3 需求工作改进措施

1)原需求管理过程

通过以上的数据分析以及在公司的调研,我们发现公司的需求管理过程存在着如下问题。需求表述与客户理解不一致导致返工;忽视对客户高层需求的获取引发问题;过程对需求分析的要求不明确,缺少分析活动;没有开展需求跟踪活动,对开发工作的真实进展以及是否达到交验状态缺乏管理审核,也缺乏相应的报告信息;需求变更记录不完整、方式随意,缺乏审核审批手续,对变更工作量管理失控;因需求变更导致需求、设计、编码文件的一致性差。

2)需求管理过程改进措施

针对公司原来的需求管理过程存在的问题,我们对需求工作提出如下改进策略及改进措施:

需求过程问题的改进:

改进的主体是公司的软件研发中心,质管部协助支持。改进的主要内容要求是将需求开发与需求管理合并为“需求工程”过程;重新定义需求开发与管理控制活动,重点加强需求开发支持和指导(模板、指南),以及加强需求管理控制的需求评审、审批、变更控制;尽可能在图形表达、文字表述、表格模板等方面进行统一要求对需求工作成果进行量化管理。

需求获取问题的改进:

改进的主要内容要求,总结好的需求获取方法、经验及问题教训,形成需求获取工作指南、知识库、或标准过程;加强需求获取前的准备工作;明确需求调研阶段性完成标准,评估需求获取的“量与质”,并为澄清需求问题、沟通达成理解一致留足时间。

需求分析问题的改进:

改进的主要内容要求,总结好的需求分析方法、经验及问题教训,形成需求分析工作指南、知识库、或标准过程;采用统一的需求规格表达样式,实现需求工作量化,支持项目规模描述、计划与监控、需求变更与跟踪;加强需求的同行评审,落实评审资源及责任。

3)改进后的结果

我们将提出的需求工作改进措施应用到具体的公司的项目中,那么从公司质量管理部门反馈的信息中,在需求开发阶段的需求工作完成较好,而在后面的设计、编码、试运行阶段的需求工作逐步减少,取得了一定的效果。

3 结束语

本文以软件过程改进为目标,给出一个基于度量的软件过程改进模型SPIM和度量信息框架,本文只对需求过程进行了深入的研究分析,给出改进措施,所以要进一步对其他的过程进行深入的研究分析。

摘要：该文以软件过程改进为指导方向,给出一个基于度量的软件过程改进模型SPIM和度量信息框架;依据SPIM和软件过程度量数据模型,针对在某软件公司的实际项目中采集的8个项目的相关数据,对需求管理方面的数据进行了度量和分析。通过度量和分析,提出过程改进意见和措施。

关键词：软件过程改进,软件过程改进模型,过程数据分析

参考文献

[1]Zahran S.软件过程改进[M].陈新,译.北京:中信出版社,2002.

[2]何新贵,王纬,王方德.软件能力成熟度模型[M].北京:清华大学出版社,2000.

[3]吴洪丽.支持软件过程改进的软件过程度量研究[D].重庆:重庆大学,2004.

常用软件度量方法分析及比较 第8篇

GQM,即Goal-Question-Measure,为软件度量最常见模型,其将度量结构分为3个层次,从高到低分别是:目标层、问题层、度量层[1]。三层逐步递进、逐步求精,将抽象级别较高的组织或项目目标与度量项实际收集的数据相关联,有利于尽快根据信息的需要和优先级决定度量并进行度量。针对软件规模、成本、复杂度、顾客满意度或其它方面的度量,都可依据此模型逐步完成度量过程。

GQM的主要步骤:1确定度量目标;2提出满足目标的问题;3确定回答问题所需要的度量[2]。GQM度量过程如图1所示。

2 规模度量方法

规模度量常用方法有功能点分析、代码估算、德尔菲法、用例点、对象点方法等。其中功能点分析方法是使用最多的一种规模度量方法。

功能点分析方法,即Function Point Analysis,是以系统的功能点来估算系统规模的一种常用方法,用功能点的数量来表示系统规模大小,而与实现语音及编程环境无关,在系统需求分析阶段即可发挥作用。

FPA有5项基本计数:1外部输入数(EI,external input);2外部输出数(EO,external output);3外部查询数(EQ,external query);4内部逻辑文件(ILF,internal logical file);5外部接口文件(EIF,external interface file)。功能点分析法的主要步骤如表1所示。

图1 GQM度量过程

表1 1 功能点分析法

功能点分析法主要适用于估算出开发前软件项目的规模,以及有很多输入输出或文件应用的软件,与程序设计语言无关。由于功能点主要由经验来估算,不同的人针对同一系统可得出完全不同的数据,主观因素较多,因此虽然可估算系统规模,但常常不太准确。

3 成本度量方法

成本度量常用方法包括构造性成本模型、类比估算、细分估算、周期估算方法。构造性成本模型COCOMO(Constructive Cost Model)最早由B.W.Boehm[4]提出,它包括3个层次:1基本模型:用已估算出的代码行长度配以相应参数来估算开发需要的工作量;2中间模型:在基本模型的基础上增加项目、人员等影响因素数据来估算工作量;3详细模型:包含中间模型的各种特性,并考虑了软件开发过程中各步骤的影响。

一般来说,基本模型适合项目信息较少的估算,中间模型在需求确定后即可使用,详细模型在项目设计完成后可使用。

模型还提供了3种软件应用开发模式,根据软件不同应用领域划分:1组织式:泛指一些比较小或者不需要太多创新的项目,比如数据的处理等;2嵌入式:指软硬件环境被严格限制的项目,比如各种系统程序等;3分离式:介于组织式和嵌入式之间的类型,指各类实用程序,如编译器、分析器等。

3.1 COCOMO基本模型

公式:Effort=a*KLOCb Time=c*Effortd Person=Effort/Time

其中:Effort是所需的人力,如人/月、人/年等。a、b、c、d是参数,如表2所示。

表2 COCOMO基本模型参数

例:开发一个估计规模为30KLOC的项目,功能主要为数据处理。分析属于组织式,估算工作量如下:

3.2 COCOMO中间模型

公式:Effort=a*KLOCb*F

其中:a、b是参数,其值如表3所示。

表3 COCOMO中间模型参数a、b

F是乘法因子,是根据成本驱动属性打分的结果。15个成本驱动因子如表4所示。

以基本模型为例,RELY、TURN、SCED因子分别取值1.15、0.87和1.08时,估算工作量:

3.3 COCOMO详细模型

公式:Effort=a*KLOCb*F

根据面向对象技术的发展,对COCOMO模型进行了改进,主要特点是:

表4 COCOMO中间模型参数F

(1)提供了3个层次的开发工作量估算模型:1应用系统组成模型:用于原型构建阶段;2早期设计模型:用于体系结构设计阶段;3后体系结构模型:用于完成体系结构设计之后的软件开发阶段。

(2)17个工作量乘数因子(Cost Drivers)。

4 复杂性度量方法

复杂性度量方法可以从面向结构的度量、面向对象的度量两个方面来分析。

4.1 结构化程序复杂性度量方法

结构化程序复杂性度量往往针对3个方面进行,即模块、结构及总体复杂性。作为程序复杂性度量的基础,模块的复杂性度量又分为程序长度和程序控制流度量。McCabe环形复杂度理论是常用的程序控制流度量方法[5]。

环形复杂度理论以图论为基础,通过程序的控制流图来获得程序的复杂度,定义如下:

其中,G为控制流图,V(G)是G中环形的数目,e是G中边的数目,n是节点个数,p是不相连部分的数量。

例:(1)根据代码画出控制流图,如图2。

(2)计算环形复杂度,可用3个数据表示:1流图中区域的数量;2流图中边的数量-流图中节点的数量+2;3流图中判定节点的数量+1。

图2 控制流图及代码

因此,对应图2,例子中的环形复杂度V(G)=4。

4.2 面向对象软件复杂性度量

面向对象软件复杂性度量方法主要有C&K方法、MOOD方法等[6],C&K方法更为常见。C&K方法给出了6个面向对象设计和复杂性的度量因子:

(1)每类加权方法数(WMC),即Weighted Methods per Class,表示一个类的静态复杂度总和,设类C1,类中定义了方法Mi,,,Mn,令c1,,,,cn为这些方法的复杂度,则:

(2)继承树深度(DIT),即Depth of Inheritance Tree,表示类继承树的最大深度。

(3)每个类的孩子数(NOC),即Number Of Children,表示直接继承本类的孩子数目。

(4)类耦合(CBO),即Coupling Between Object classes,表示和本类耦合的类数目。

(5)类的响应(RFC),即Response For a Class,为本类方法及本类调用方法的数目和。

(6)方法间内聚缺乏(LCOM),即Lack of Cohesion in Methods,为相似度为0的方法对减去相似度不为0的方法对的数量,该数目越大表示类的内聚越强。

C&K方法的6个度量因子能在一定程度说明面向对象软件的复杂性,但仍存在一定的缺陷,譬如:1针对WMC,未说明如何继承的情况;2针对DIT,定义有二义性,多继承情况考虑不全面;3针对NOC,未考虑间接继承孩子,得到的度量结果比较扭曲;4针对RFC,容易区分是否为本类方法,不易区分是否为系统函数;5针对CBO,根据多种情况进行判断;6针对LCOM,没有访问属性方法的百分比,度量有一定缺陷;7缺少对封装性的度量;8缺少对多态性的度量。

针对这些不足,使用时可以对每个度量进行改进,比如:1WMC将基类的公有、保护函数计入本类;2DIT可以将多个继承定义为单个继承的和;3NOC将间接继承的孩子考虑进来;4RFC不区分本类方法,只统计出所有被本类调用的方法;5CBO考虑多种情况的耦合,得到最终数目;6LCOM提出克服一些缺陷的定义;增加了对封装性、多态性的度量。

5 结语

本文针对不同的度量内容介绍了常用的度量方法,包括功能点分析方法、COCOMO模型、环形复杂度理论和C&K方法[7]以及GQM模型,这些方法可用于软件度量。此外,软件度量往往涉及多个学科或技术,在对其进行学术研究或实际应用时,应适当结合多领域技术,以促进度量目标实现。

参考文献

[1]周宇,钱红兵.软件过程中的度量数据收集方法研究[J].计算机应用研究,2005,22(1):1-2.

[2]王汝沛.软件度量指标研究及实现[J].数字技术与应用,2012(3):85-87.

[3]IFPUG(International Function Point Users Group).Func-tion point counting practices manual-release 4.2[R].Westerville,2004.

[4]BOEHM B W.软件成本估算COCOMO II模型方法[M].北京:机械工业出版社,2005.

[5]邓小鹏,邢春晓,蔡莲红.Web应用测试技术进展[J].计算机研究与发展,2007(8):1273-1283.

[6]易彤.面向对象设计中软件度量学:回顾与热点[J].计算机应用研究,2011,28(2):427-434.

一种改进的软件过程质量度量方法 第9篇

1 软件过程质量

软件过程是指软件项目从需求、设计、编码、测试、 发布及维护整个生命周期内实施的一系列活动、技术方法及相关产品的集合。软件的过程质量可分解为软件需求、设计、编码、测试以及运行维护等5 个阶段的过程质量,每个阶段的质量由该阶段的共性和个性质量因素共同决定。每个共性或个性质量因素根据项目特点和组织需要又可进一步分解为一个或多个子质量因素,从而获得最终的度量数据［1 －4］。

在软件开发过程中,提高软件生产效率、改善软件质量以及降低成本这3 个方面的要求贯穿于整个软件开发生命周期,软件过程度量也主要围绕这3 个方面来进行,本文根据这3 个方面的主要特点,归纳出8 个共性质量要素,分别为进度、资源和费用、性能、缺陷、需求稳定性、技术完备性、评审有效性、过程依从性［5 －7］。

个性质量因素则是只跟软件项目类型或软件项目开发过程中各个不同阶段相关的质量因素,其具体表现形式由该软件类型或该软件各开发阶段决定,比如软件测试阶段的测试用例。

2 模糊综合评价

本文采用模糊综合评价方法来对软件过程质量进行度量分析。模糊综合评价是指在对某事物进行优劣评价时,根据事物的自身特点和状态,综合考虑影响该事物的各个因素,并运用模糊统计方法进行计算并得出评价结论的一种科学方法［8 －10］。

2. 1 单级模糊综合评价

( 1) 确定评价集,它是由评语组成的集合V

( 2) 根据评价目的和评价对象确定要评价的指标,建立评价因素集U

( 3) 由于各因素的重要程度不一致,需对各因素加权,从而建立评价因素权重集A

各因素权重应当满足归一性和非负性,即,且ai≥ 0。

( 4) 进行单因素评判,建立评价矩阵R

( 5) 根据选取的模糊变换算子,对权重集A与单因素评判矩阵R进行合成,从而得到评判结果

(6)作出评价结论。

2.2多级模糊综合评价

在实际软件项目中,由于项目的复杂性和需求的多样性,评价对象涉及的评价因素一般都比较多,采用单级模糊综合评价方法容易导致各因素由于权重小而造成评价结果严重失真。本文采用改进的多级模糊综合评价模型,具体过程如下:

设U是因素集,先按不同属性或性质将U中元素分组

再对每一组选取单因素组成集合

确定权重时,要对每一个层次的因素确定权重

A为较高层次各因素权重集,i≤m,Ai为较低层次的权重集。

首先在较低层次上进行综合评价,先进行单因素评判,得到各组因素的评判结果Bi

当各组因素评判完成后,接着在较高层次上进行最终的模糊变换,得到评判结果B

3 软件过程质量度量应用

以某高校教务管理系统为例,选取其测试过程来进行度量分析。

3. 1 建立评价集

3. 2 评价因素集和权重分配

通过分析该软件测试过程的共性质量因素跟个性质量因素,并采用层次分析法确定各质量因素的权重［1］,建立如表1 所示的度量因素体系。

3. 3 单因素评判

采取专家评分的方式对各因素评审打分,从而建立单因素评价矩阵R,如表2 所示。

3.4多级模糊综合评价

(1)一级评价。进度

同理可计算出B12、B13、B14、B15、B16、B17、B18、B21、B22。

( 2) 二级评价。共性质量要素

同理可计算出个性质量要素B2。

( 3) 三级评价。测试过程质量

3. 5 评价结果分析

根据多级模糊综合评价模型,可以得到一个数值向量B,但这个结果并不能直观地表示出该软件测试过程质量水平,需要对B进行分析处理,才能得出一个定性的评价结论。本文采用最大隶属度法和加权平均法两种方法对评价结果进行对比分析。具体过程如下:

(1)最大隶属度法。根据bk=max(b1,b2,…,bm)得到该软件测试过程质量属于“优秀”等级。

( 2) 加权平均法。给每个评价等级设定一个分值C = ( 1,2,3,4) ,根据进行计算, 从而得到

该结果值所对应的测试过程质量介于良好和一般之间,偏向良好的程度高,由此得出结论该软件测试过程质量属于“良好”等级。

可以看出,上述两种分析方法得出的结论并不一致,但对这两种方法经过对比分析发现,最大隶属度法只考虑了影响最大的因素,而忽略了其他有效信息,得到的结果比较粗糙,存在较大的误差,而加权平均法综合考虑各项因素的影响,包含信息相对全面,其结果相对真实、合理,所以该教务管理系统项目测试过程的质量最终评定为“良好”等级。

4 结束语

为按时高效、在预算范围内生产出高质量的软件产品,软件过程的规范化和度量分析已经引起了软件组织和工程人员的高度重视,但由于软件过程本身的复杂性及特殊性,使得对软件过程质量的度量存在一定的困难,缺乏统一的度量标准和度量体系。本文以软件过程的几个阶段为出发点,对其分解为若干共性和个性质量因素,并根据需要进行进一步细化,利用模糊理论建立多级综合评价体系,实现软件过程质量的定量度量。

摘要：为了有效地对软件过程进行度量分析,生产高质量软件产品,提出了一种改进的软件过程质量度量方法。该方法将软件过程分解为软件需求、设计、编码、测试以及运行维护等5个阶段,从共性和个性两个不同的角度将每个阶段分解为若干质量因素,根据多级模糊综合评价方法对各质量因素进行评判,最后通过实例验证了该方法的有效性和合理性。