UML软件工程组织

为何编程水平决定软件质量
文章出处:blog  作者:不详

1.软件质量的内涵

首先再来看PMBOK对质量的定义是内在的系列特征满足要求的程度。这里我们的关注点是这个要求是谁的要求,如果仅仅理解为最终的使用软件的用户的要求,那就片面的理解了软件的质量。因此这里的要求应该理解为满足内部用户和外部用户的要求。

◆外部用户要求

正确,高效,健壮,易用和可靠

◆内部维护人员要求

可维护(代码易读,易读,易Debug,注释清晰,容易扩展)

◆内部测试人员要求

可测试,易用,易理解

◆企业产品化要求

可扩展,可移植,可配置,灵活,重用性高,模块和组件化

因此质量不是无中生有,是有具体的需求驱动,质量也是为了满足某种需求。但一开始可能我们并不能意识到这种需求,如一开始并不注意软件可维护性,到了后期随着需求不断变更修改和人员交替,软件维护拖垮掉项目一半人员时候才反省软件可维护性的重要性,才来关注这个质量需求并制订相应的质量目标。

只有当所有人由于没有执行某些规则而导致惨痛代价后,人们才可能真正理解规则的价值。

因此《代码大全》将软件质量特征分为内部质量特征和外部质量特征:

外部质量特征包括:

◆正确性

整个系统受说明、设计和实现的错误影响程度。

◆可用性

用户学会和使用系统的难易程度。

◆效率

对系统资源的最小利用,包括存储和执行时间。

◆可靠性

在一定条件下执行特定功能的能力。

◆完整性

防止非法或不适当地访问。完整性思想包括:限制非法用户访问,同时确保证数据恰当访问;并行数据表进行并行修改;数据段仅含有有效数据等等。

◆适应性

系统在应用或其它环境下不作修改就能使用的能力。

◆精确性

系统不受错误影响的程度,尤其是数据输出方面。精确性和正确性是不同的。精确性是对系统完成其工作性能良好的衡量,而不是它设计得是否正确。

◆坚固性

系统对无效输入或压力环境中能继续执行其功能的能力。

内部质量特征包括:

◆可维护性

修改一个软件系统,提高其性能或修正其错误的能力。

◆灵活性

修改系统使其能适应于不同的用途或环境的能力,而不必对系统进行特定的设计。

◆可移植性

能修改所设计的某一系统使其能在其它环境下运行的能力。

◆可重用性

能将系统的一部分用于其它系统的难易程度。

◆可读性

能读懂或理解系统源代码的能力,尤其是在细节说明这一级上。

◆可测试性

对整个系统进行单元或系统测试以证实其满足所有需求性能的测试难易程度。

◆可理解性

能从整个系统水平或细节说明这一级上理解整个系统的难易程度。可理解性要比可读性从更一般的水平上讨论系统的紧密性。

对于一个实际的软件项目而言,想把上面的所有质量特征都做好是一件很难的事情,尤其是在项目有明确的进度压力下面。质量,资源和时间是项目管理的三要素,三者相互影响和制约,提高质量是有成本和代价的,提高质量可能带来更多资源的投入或进度的延后。因此项目经理的关注点就是如何根据项目的实际特点来平衡好这三要素,制订切实可行的质量目标。

2.提高软件质量的方法

首先应该确认的是质量需要一个持续改进和提高的过程。谈提高软件质量就是首先要有历史参照,根据参照制定新的质量目标,然后对产品进行验证达到新的更高级别的目标。你的软件是否可维护不是某个开发人员说了算,而是应该有一套明确的标准和准则。

PMBOK里面对于质量管理过程组提及到实施质量保证和实施质量控制两个重要的过程。质量保证是确保项目按照组织定义的过程在做事情;而质量控制是对你的结果进行检查,看是否达到了预期的质量目标。在CMMI里面我们关注过程改进和软件质量的关系,过程改进是否真正提高软件质量,一个重点就是过程的有效性问题,如果我们能干确保过程是有效的,那是肯定可以提高软件质量的。

CMMI中的每一个过程都是其它软件企业多年的积累,有可以借鉴的地方。过程并不是要多繁琐或者说一定要采用什么方法工具,关键在于你采用的过程是否真正有效,因此任何走形式主义的过程最终结果都是失败。

软件质量保证是一种重要的质量活动,最终的目的还是要提高软件质量,而有效的方法就是关注软件开发生命周期,关注软件开发的各阶段的活动。只有每个阶段都满足要求,才可能保证整个软件质量。

对于一个好的软件质量管理计划,应该包含以下内容:

◆质量目标

没有目标就谈不上改进和衡量质量是否提高基准。质量目标分为大目标和小目标,大目标对于软件产品而言最重要的就是软件发布后的缺陷情况。而为了达到这个大目标需要执行评审,Review,测试等各种活动,需要将大目标分解为各种小目标:如缺陷的泄漏率目标,评审的覆盖率情况,测试的覆盖率情况等。

◆质量保证活动

项目进行过程中需要进行哪些质量保证活动?对于管理过程,技术过程,各阶段的输出都需要有相关的质量保证活动。在一些组织中,确定质量保证活动确定质量保证活动急促和草率的编程往往是一件常见的事。程序代码充满错误但能很快完成编程的程序员往往能得到更多的奖励。而高质量的程序员。虽然编出的程序优秀而且确保其是可用的,却往往得不到这种礼遇。[注]代码大全专门提及到质量保证活动的一个重要作用是让开发人员意识到软件质量是第一位的,形成质量意识,但这点却经常无法做到。

◆测试策略和计划

测试策略或计划一般需要单独出相关的计划或文档,但整个测试策略仍然要以项目需要达到的质量目标为依据来制定。

◆软件工程准则

需要遵守的生命周期模型,需求规范,设计规范,编码规范,界面规范,测试流程和规范等。这些都属于软件工程准则的内容,而且很多规范要在项目一开始就约定好并严格执行,这样才能够保证项目成员有共同的语言。

◆评审

预防总是比补救的成本低,因此评审在软件开发中更应该受到关注。正式的审查,非正式评审,互查,代码Review和走读等都是很好的评审手段,项目应该根据实际情况和质量目标来确定各阶段采用哪些评审方式,评审的覆盖率目标等。

◆质量数据的度量

质量保证计划的结果应该是可以度量的,否则无法知道改进工作的效果。因此在质量控制中我们关注对结果进行度量,分析度量数据以判断实际的数据是否满足了预先定义的质量目标。当偏差超过我们预定义的限度后还要分析问题,查找根源,进行纠正和预防。

根据《编程效率》一书,没种方法发现缺陷的比例在通常情况下都不会超过65%,因此为了达到质量目标一般需要联合使用一种或多种方法或活动。

3.软件质量的一般原则

提高效率和质量的最好方法是减少代码再加工的时间,不论再加工是由于要求的变更、设计的修改或调试调试通常要占一个传统的初始软件开发周期的50%。消除掉防止错误的软件调试可提高生产率。因此,缩短软件开发时间最为明显的方法是提高产品质量,减少调试和再开发软件所需时间。

如果不顾质量而只是想用最短的时间将软件开发出来,往往很可能需要较长的时间和花费超出。从一开始就着眼于取得最高可能质量和可靠性的软件开发,易于取得最好的开发进度、最高的生产率甚至是最好的市场成功率。

前期活动较后期对产品质量有更大的影响,你在前期活动中所投入的时间将会节省更多的后期时间。其结果是较少的错误、较短的开发时间和较低的代价。

 

版权所有:UML软件工程组织