一、引言
J.M.Juran认为质量控制是一个常规的过程,通过它度量实际的质量性能并与标准比较,当出现差异时采取行动。由此,DonaldReifer 给出软件质量控制的定义:软件质量控制是一系列验证活动,在软件开发过程的任何一点进行评估开发的产品是否在技术上符合该阶段制定的规约。
二、软件缺陷分析
在IEEE 1983 of IEEES tandard729 中对软件缺陷下了一个标准的定义:从产品内部看,软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题;从外部看,软件缺陷是系统所需要实现的某种功能的失效或违背。
软件缺陷是一个更广的概念,而软件错误(error)属于缺陷的一种———内部缺陷,往往是软件本身的问题,如程序的算法错误、语法错误或数据计算不正确、数据溢出等。软件错误往往导致系统某项功能的失效,或成为系统使用的故障。软件的故障、失效是指软件所提供给用户的功能或服务,不能达到用户的要求或没有达到事先设计的指标,在功能使用时中断,最后的结果或得到的结果是不正确的。
软件缺陷的产生主要是由软件产品的特点和开发过程决定的,如软件的需求经常不够明确,而且需求变化频繁,开发人员不太了解软件需求,不清楚应该 “做什么”和“不做什么”,常常做不合需求的事情,产生的问题最多。同时,软件竞争非常激烈,技术日新月异,使用新的技术也容易产生问题。
从软件自身特点、团队工作和项目管理等多个方面进一步分析,就比较容易确定造成软件缺陷的一些原因细节,归纳如下:
(一)软件自身特点造成的问题。
需求不清晰,导致设计目标偏离客户的需求,从而引起功能或产品特性上的缺陷。系统结构非常复杂,而又无法设计成一个很好的层次结构或组件结构, 结果导致意想不到的问题或系统维护、扩充上的困难;即使设计成良好的面向对象的系统,由于对象、类太多,很难完成对各种对象、类相互作用的组合测试,而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。
新技术的采用,可能涉及技术或系统兼容的问题,事先没有考虑到。
对程序逻辑路径或数据范围的边界考虑不够周全,容易在边界条件出错或超过系统运行环境的复杂度。
系统运行环境的复杂,不仅用户使用的计算机环境千变万化,包括用户的各种操作方式或各种不同的输入数据,容易引起一些特定用户环境下的问题;在系统实际应用中,数据量很大,可能会引起强度或负载问题。
对一些实时应用系统,要进行精心设计和技术处理,保证精确的时间同步,否则容易引起时间上不协调,或不一致性所带来的问题。
没有考虑系统崩溃后系统的自我恢复或数据的异地备份等问题,从而存在系统安全性、可靠性的隐患。
由于通信端口多、存取和加密手段的矛盾性等,会造成系统的安全性或适用型等问题。
(二)软件项目管理的问题。
缺乏质量文化,不重视质量计划,对质量、资源、任务、成本等的平衡性把握不好,容易挤掉需求分析、评审、测试等时间,遗留的缺陷会比较多。系统分析时对客户的需求不是十分清楚,或者和用户的沟通存在一些困难。开发周期短,需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来。开发流程不够完善,存在太多的随机性和缺乏严谨的内审或评审机制,容易产生问题。文档不完善、风险估计不足等。
(三)团队工作的问题。
不同阶段的开发人员相互理解不一致,软件设计人员对需求分析结果的理解偏差,编程人员对系统设计规格说明书中某些内容重视不够,或存在着误解。设计或编程上的一些假定或依赖性,没有得到充分的沟通。项目组成员技术水平参差不齐,新员工较多,或培训不够等原因也容易引起问题。
软件缺陷是由很多原因造成的,但如果把这些缺陷按整个软件开发周期的结果———软件产品(市场需求文档、规格说明书、系统设计文档、程序代码、测试用例等) 归类起来,统计结果发现,规格说明书是软件缺陷出现最多的地方。
软件产品规格说明书是软件缺陷存在最多的地方,主要原因如下:
用户一般是非计算机专业人员,软件开发人员和用户的沟通存在较大困难,对要开发的产品功能理解不一致。
由于软件产品还没有设计、开发,完全靠想象去描述系统的实现结果,所以有些特性还不够清晰。
用户的需求总是在不断变化的,容易引起前后文、上下文的矛盾和需求描述的不一致。
需求分析没有得到足够重视。在规格说明书设计和写作上投人的人力、时间不足。排在产品规格说明书之后的是设计,编程排在第三位。而许多人印象中,软件测试主要是找程序代码中的错误,从分析看,这是一个误区。
如果从软件开发各个阶段所能发现的软件缺陷分布来看,也主要集中在需求分析、系统设计阶段,代码阶段的错误要比前两个阶段少。
三、分析及应对措施
(一)定义合适的项目过程。
软件过程是指开发和维护软件产品的活动、技术和实践的集合。在以计算机网络为基础的现代社会信息化背景下,过程管理作为现代企业管理的先进思想和有效工具,随着外部环境与组织模式的变化而变化。因此,作为一个好的软件项目过程,必须针对企业和项目的实际情况,确定软件项目运作流程,定义软件功能及相关性能,明确各阶段的进入条件和退出条件,进行有效的过程控制与管理,在提高软件开发的效率和项目的成功率的基础上进一步保证所开发软件的质量。
(二)明确项目需求。
对于任何软件项目过程而言,需求不仅是一个不可避免的环节,也是软件开发的基础。往往用户需求明确、变更少的项目的成功率就高,而那些用户需求混乱、变更频繁的项目几乎从一开始就注定了失败的命运。但是,在现实生活中,用户需求总是在开发进入中后期时,因为各种不同的原因而发生变化。这就给软件项目过程实施带来不确定因素。在涂装项目中,由于前期需求不明确以及随意变更需求,导致项目组在开发阶段不停的返工,进而造成代码质量低下,测试拖期等一系列问题。因此,在项目实施过程中,为了保证软件开发的顺利进行和最后交付的产品质量,应该对项目需求变更进行管理。
1、需求说明书要描述明确、详尽。由于与用户沟通的需求人员并不是最后的开发人员,所以有可能导致开发人员对需求说明书的理解与用户真正的意图会产生一定的偏差。另外,当项目在进行到开发(编码)阶段时,由于记忆的缺失,对当初所作的需求说明书的理解也会产生偏差。
2、要对需求变更进行管理。通常需求分析完成后项目就进入开发阶段,用户可能会因为市场或策略的变化而提出需求变更的要求。此时,若是合理变更则有利于项目实施,但有时所作的变更可能会影响项目整体的设计和开发,造成项目进度的延期。对于这一情况,项目组应该积极与用户沟通,制订需求变更说明书,在双方都认可的情况下方可实施。
3、在项目开发过程中要尽早明确用户需求,有些内容一时无法确定则应该暂缓该部分的开发,尽量降低因需求变更而带来的风险。
(三)代码走查。
软件质量在很大程度上依赖于代码质量。在实际环境中对于同一项目而言,由于项目组成员的编程能力、习惯、风格、对需求的理解和个性的不同,所开发的代码质量也不尽相同。再加上一些难以预测的人为因素,由此带来的隐患将严重影响代码质量,最终造成软件质量低下,使得用户无法正常使用并为以后的维护带来更大的工作量和难度。
在软件开发过程中可以根据需要引进代码走查。每周在规定的时间内,轮流让程序员讲解其所开发代码的主要部分。这项措施一方面可以从侧面促使程序员本人注意所开发代码的质量,另一方面在走查过程中可以获得他人的意见进一步改善代码效率,使开发成员共享项目实施过程中问题解决的思路和方法,使得软件质量更有保障。
(四)进行正式的测试,并形成制度测试就是对软件产品的检验。
项目测试分集成测试和系统测试,主要进行功能测试、健壮性测试、性能-效率测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等活动。测试过程通常在模拟环境中进行。要尽可能覆盖整改项目过程,从最初的需求到部署阶段,都应该制订详细的计划并编制相应的文档,如测试计划、测试用例文档、测试报告等。通过测试活动,尽可能早得发现每个阶段中软件存在的缺陷,以方便后续阶段的实施。总之,一切测试应该符合用户需求。