浅谈软件开发项目的质量控制

1、引言

 

　　J.M.Juran认为质量控制是一个常规的过程,经过它度量实际的质量性能并与标准比较,当出现差别时采起行动。由此,DonaldReifer 给出软件质量控制的定义:软件质量控制是一系列验证活动,在软件开发过程的任何一点进行评估开发的产品是否在技术上符合该阶段制定的规约。

 

　　2、软件缺陷分析

 

　　在IEEE 1983 of IEEES tandard729 中对软件缺陷下了一个标准的定义:从产品内部看,软件缺陷是软件产品开发或维护过程当中所存在的错误、毛病等各类问题;从外部看,软件缺陷是系统所须要实现的某种功能的失效或违背。

 

　　软件缺陷是一个更广的概念,而软件错误(error)属于缺陷的一种———内部缺陷,每每是软件自己的问题,如程序的算法错误、语法错误或数据计算不正确、数据溢出等。软件错误每每致使系统某项功能的失效,或成为系统使用的故障。软件的故障、失效是指软件所提供给用户的功能或服务,不能达到用户的要求或没有达到事先设计的指标,在功能使用时中断,最后的结果或获得的结果是不正确的。

 

　　软件缺陷的产生主要是由软件产品的特色和开发过程决定的,如软件的需求常常不够明确,并且需求变化频繁,开发人员不太了解软件需求,不清楚应该 “作什么”和“不作什么”,经常作不合需求的事情,产生的问题最多。同时,软件竞争很是激烈,技术突飞猛进,使用新的技术也容易产生问题。

 

　　从软件自身特色、团队工做和项目管理等多个方面进一步分析,就比较容易肯定形成软件缺陷的一些缘由细节,概括以下:

 

　　(一)软件自身特色形成的问题。

 

　　需求不清晰,致使设计目标偏离客户的需求,从而引发功能或产品特性上的缺陷。系统结构很是复杂,而又没法设计成一个很好的层次结构或组件结构, 结果致使意想不到的问题或系统维护、扩充上的困难;即便设计成良好的面向对象的系统,因为对象、类太多,很难完成对各类对象、类相互做用的组合测试,而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。

 

　　新技术的采用,可能涉及技术或系统兼容的问题,事先没有考虑到。

 

　　对程序逻辑路径或数据范围的边界考虑不够周全,容易在边界条件出错或超过系统运行环境的复杂度。

 

　　系统运行环境的复杂,不只用户使用的计算机环境变幻无穷,包括用户的各类操做方式或各类不一样的输入数据,容易引发一些特定用户环境下的问题;在系统实际应用中,数据量很大,可能会引发强度或负载问题。

 

　　对一些实时应用系统,要进行精心设计和技术处理,保证精确的时间同步,不然容易引发时间上不协调,或不一致性所带来的问题。

 

　　没有考虑系统崩溃后系统的自我恢复或数据的异地备份等问题,从而存在系统安全性、可靠性的隐患。

 

　　因为通讯端口多、存取和加密手段的矛盾性等,会形成系统的安全性或适用型等问题。

 

　　(二)软件项目管理的问题。

 

　　缺少质量文化,不重视质量计划,对质量、资源、任务、成本等的平衡性把握很差,容易挤掉需求分析、评审、测试等时间,遗留的缺陷会比较多。系统分析时对客户的需求不是十分清楚,或者和用户的沟通存在一些困难。开发周期短,需求分析、设计、编程、测试等各项工做不能彻底按照定义好的流程来。开发流程不够完善,存在太多的随机性和缺少严谨的内审或评审机制,容易产生问题。文档不完善、风险估计不足等。

 

　　(三)团队工做的问题。

 

　　不一样阶段的开发人员相互理解不一致,软件设计人员对需求分析结果的理解误差,编程人员对系统设计规格说明书中某些内容重视不够,或存在着误解。设计或编程上的一些假定或依赖性,没有获得充分的沟通。项目组成员技术水平良莠不齐,新员工较多,或培训不够等缘由也容易引发问题。

 

　　软件缺陷是由不少缘由形成的,但若是把这些缺陷按整个软件开发周期的结果———软件产品(市场需求文档、规格说明书、系统设计文档、程序代码、测试用例等) 归类起来,统计结果发现,规格说明书是软件缺陷出现最多的地方。      

 

软件产品规格说明书是软件缺陷存在最多的地方,主要缘由以下:

 

　　用户通常是非计算机专业人员,软件开发人员和用户的沟通存在较大困难,对要开发的产品功能理解不一致。

 

　　因为软件产品尚未设计、开发,彻底靠想象去描述系统的实现结果,因此有些特性还不够清晰。

 

　　用户的需求老是在不断变化的,容易引发先后文、上下文的矛盾和需求描述的不一致。

 

　　需求分析没有获得足够重视。在规格说明书设计和写做上投人的人力、时间不足。排在产品规格说明书以后的是设计,编程排在第三位。而许多人印象中,软件测试主要是找程序代码中的错误,从分析看,这是一个误区。

 

　　若是从软件开发各个阶段所能发现的软件缺陷分布来看,也主要集中在需求分析、系统设计阶段,代码阶段的错误要比前两个阶段少。

 

　　3、分析及应对措施

 

　　(一)定义合适的项目过程。

 

　　软件过程是指开发和维护软件产品的活动、技术和实践的集合。在以计算机网络为基础的现代社会信息化背景下,过程管理做为现代企业管理的先进思想和有效工具,随着外部环境与组织模式的变化而变化。所以,做为一个好的软件项目过程,必须针对企业和项目的实际状况,肯定软件项目运做流程,定义软件功能及相关性能,明确各阶段的进入条件和退出条件,进行有效的过程控制与管理,在提升软件开发的效率和项目的成功率的基础上进一步保证所开发软件的质量。

 

　　(二)明确项目需求。

 

　　对于任何软件项目过程而言,需求不只是一个不可避免的环节,也是软件开发的基础。每每用户需求明确、变动少的项目的成功率就高,而那些用户需求混乱、变动频繁的项目几乎从一开始就注定了失败的命运。可是,在现实生活中,用户需求老是在开发进入中后期时,由于各类不一样的缘由而发生变化。这就给软件项目过程实施带来不肯定因素。在涂装项目中,因为前期需求不明确以及随意变动需求,致使项目组在开发阶段不停的返工,进而形成代码质量低下,测试拖期等一系列问题。所以,在项目实施过程当中,为了保证软件开发的顺利进行和最后交付的产品质量,应该对项目需求变动进行管理。

 

　　一、需求说明书要描述明确、详尽。因为与用户沟通的需求人员并非最后的开发人员,因此有可能致使开发人员对需求说明书的理解与用户真正的意图会产生必定的误差。另外,当项目在进行到开发(编码)阶段时,因为记忆的缺失,对当初所做的需求说明书的理解也会产生误差。

 

　　二、要对需求变动进行管理。一般需求分析完成后项目就进入开发阶段,用户可能会由于市场或策略的变化而提出需求变动的要求。此时,如果合理变动则有利于项目实施,但有时所做的变动可能会影响项目总体的设计和开发,形成项目进度的延期。对于这一状况,项目组应该积极与用户沟通,制订需求变动说明书,在双方都承认的状况下方可实施。

 

　　三、在项目开发过程当中要尽早明确用户需求,有些内容一时没法肯定则应该暂缓该部分的开发,尽可能下降因需求变动而带来的风险。

 

　　(三)代码走查。

 

　　软件质量在很大程度上依赖于代码质量。在实际环境中对于同一项目而言,因为项目组成员的编程能力、习惯、风格、对需求的理解和个性的不一样,所开发的代码质量也不尽相同。再加上一些难以预测的人为因素,由此带来的隐患将严重影响代码质量,最终形成软件质量低下,使得用户没法正常使用并为之后的维护带来更大的工做量和难度。

 

　　在软件开发过程当中能够根据须要引进代码走查。每周在规定的时间内,轮流让程序员讲解其所开发代码的主要部分。这项措施一方面能够从侧面促使程序员本人注意所开发代码的质量,另外一方面在走查过程当中能够得到他人的意见进一步改善代码效率,使开发成员共享项目实施过程当中问题解决的思路和方法,使得软件质量更有保障。

 

　　(四)进行正式的测试,并造成制度测试就是对软件产品的检验。

 

　　项目测试分集成测试和系统测试,主要进行功能测试、健壮性测试、性能-效率测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等活动。测试过程一般在模拟环境中进行。要尽量覆盖整改项目过程,从最初的需求到部署阶段,都应该制订详细的计划并编制相应的文档,如测试计划、测试用例文档、测试报告等。经过测试活动,尽量早得发现每一个阶段中软件存在的缺陷,以方便后续阶段的实施。总之,一切测试应该符合用户需求。