《论软件质量保证的实施.doc》由会员分享，可在线阅读，更多相关《论软件质量保证的实施.doc（6页珍藏版）》请在金锄头文库上搜索。
1、论软件质量保证的实施概要：软件的质量一直是软件用户，开发商，以及开发者关注的焦点。但随计算机技术的发展，软件的质量没能有显著的改善，在一些案例中，它反而是更糟糕。怎样提高软件的质量？人们在不断的探索，希望银弹的出现。本文首先回顾了软件质量走过的历程，再从现已提出的软件质量保证的理论出发，在比较传统的螺旋模型和XP方法的基础上，讨论了软件保证的关键域的实施。关键字：质量保证XP编程评审软件测试CMMISO9001质量体系一、 引子软件开发已经走过了五十多年，随着计算机硬件的飞速发展，伴随软件开发的程序设计语言也取得了长足的发展，社会和经济对软件的需求是越来越广，越复杂。软件质量的难以控制，开发进
2、度的成倍延迟，从业者素质等等问题，困惑着软件的发展。软件由上个世纪的五十年代的战争的需要而开始，在50年代，在严厉地编写文档，复查，贯彻数学试验的基础上，由那些为战争服务的物理学家和数学家小心翼翼地处理程序任务。这时的计算任务是些简单问题：运算法则和数学计算，程序环境是最基本的指令和操作，硬件只是些简单的灵活的通信协议可编程的外围设备。这时的软件质量是无与伦比的。从上世纪的60年代始，硬件的快速发展，软件开发的流行，计算机和软件开发成为公众可及的事物，计算机所能解决的问题在范围和复杂度也在增长，为解决这些问题而设计的程序语言也变的更强大更容易使用。因此，在松散的思想下，由缺少培训的从业者开始了
3、软件产业，软件缺陷也开始广泛流行。但不存在个人编译器，编译过程的痛苦让程序员们不得不在上机前审查自己的程序，直到审查了每个可能的路径。这时软件仍获得了前十年同样高质量，但高质量的保证开始远去：严格的规范和高素质的从业者。在70年代，PC使得计算机真正成为所有人的工具，程序环境的提高，使六十年代的高质量的约束逝去。问题的复杂度的提高，缺少培训的从业者。这时程序员无视缺陷，用户不理解软件，软件发展进入了混沌时代。软件质量达到最低点，其根源是以代码为中心而不是质量为中心。人们开始寻求改善，提出了规范和测试，但被误解和滥用。到了80年代，两个方面是特别显著：CASE工具的产生和正规化方法的使用，是两个
4、软件质量问题的主要的解决方案。对软件质量的补救，使得软件质量有了提高。但CASE的自身质量和正规化方法的难以使用，严重影响了它们的对软件质量改善的作用。这时程序环境快速发展，程序语言，编译器，调试器等工具广泛使用，问题比以前更复杂，从业者的素质仍需要提高，CASE和正规化方法纠正了坏的软件开发思想。90年代的软件过程改进是另一个软件质量问题的主要的解决方案。CMM, ISO9001质量体系等提出了：软件开发是一个管理的问题，控制软件生产进程来保证获得好的软件。回顾软件发展的历程，不难发现严格的过程控制，培训有素的从业者是软件质量的关键，而问题域的复杂度，程序环境是软件质量的挑战。软件开发的历程
5、从原始的严格过程和高素质的从业者发展，经历了浮躁的年代后，不得不重新找回失去的好的方法，在问题的复杂性发展的激励，从而形成现在的软件工程学。二、 基本概念未来的十年，软件工程学能带给软件质量什么？主流迭代瀑布软件开发方法与极限编程方法发展，能带来什么？Sun One， .Net能给我们获得创造可靠的高质量软件的能力？未来几年是程序环境和工程学发展的年代，能解决软件质量难题？这些努力主要来自两个方面：软件开发过程和程序环境，其中软件开发过程更为注意;目的只有一个：高质量的软件。影响软件质量的因素见图-1。软件质量保证是为了保证软件高质量的而必需的有计划的和系统化的行动模式。质量保证活动包括：软件
6、过程定义，SQA计划，软件评审，正式技术评审，度量与改进。图-1 McCall的软件质量因素软件开发过程，也简称为软件过程，是一个公共过程框架。它分为：管理及保证，子任务集。管理及保证包括：过程控制，配置管理，风险管理，复审和评审，支持和培训，度量与改进。每个子任务包括：问题定义，实现，测试，确认和批准。目前广泛实施的过程模型有：RAD，螺旋模型，基于构件的开发和敏捷模型。从企业的角度，软件过程就是软件架构。一个软件企业的软件架构是适用于企业的所有软件项目开发的总体框架。从单个项目的角度，软件过程就是对本企业的软件架构的裁减，补充，以适应于项目的特殊性。对于过程的定义，对软件企业是非常重要的，
7、它是高质量软件生产的基础，使软件质量保证活动的前提。一般由企业的高级系统架构师设计，推行和改进。对过程的评审有ISO9001，CMM等标准可以参考和评估。三、 质量保证计划在一个项目立项后，QA或项目组首先要进行质量保证计划并形成正式文档，经项目QA组批准。软件质量保证计划主要包括以下内容：1管理2文档3标准，约定，规范和节奏4复审和评审5测试6问题报告和纠正7工具，技术和方法8代码控制9媒体控制10支持控制11记录收集，维护和保持12培训13风险管理这是IEEE的标准，在实施中需要集合具体的项目进行裁减。但有几点是必须，不论是螺旋模型，还是敏捷模型：评审，测试和代码控制。评审是对软件开发过程
8、中的每个里程碑的结果质量保证活动；测试贯穿整个软件开发过程，从需求定义到软件产品维护，测试都是非常重要环节。源代码是软件产品的实现，代码控制直接影响产品的质量。质量保证计划在整个软件开发中，是软件开发过程定义的继续和实现，是软件开发管理的框架。基于IEEE的指南，质量保证计划首先说明项目组的结构，任务和所对应的责任人。接着是整个项目过程中将涉及到的文档和标准，配置管理，复审和评审，测试。虽然在XP编程中不强调文本文档，它要求代码既文档代码的易读；也只是对设计，测试等部分文档的裁减，由于XP编程，是测试先行，实现后进行重构。鉴于我们公司的开发模式以开发为中心，质量保证为辅佐，质量保证计划缺少实施
9、的保证，软件架构处于起步阶段。对质量保证可以实施裁减，基于XP的模式，保留质量保证中的标准和规约，复审和评审，测试和风险管理等活动。但应要逐步完善软件开发过程的定义和标准化。四、 配置管理在质量保证计划的基础上，要进行配置管理。配置管理就是一组用于在软件的整个生存期内管理变更的活动。它的主要目的是控制变更。基线，配置项是配置管理的两个基本概念。基线既是已经通过正式评审和批准的规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制规程被改变。配置项是为软件工程的一部分而创建的信息。配置管理活动主要包括：配置项标示，变更控制，状态记录，报告及评审。软件的复杂性，商业或市场条件的变动
10、，客户需求的改变等因素，导致软件配置项需要相应变更。软件配置管理的目标是改进变更可以被适应的容易程度，并减少当变更必须发生时所需花费的工作量。实施软件配置管理首先要制定适当的配置管理计划，需要适当的配置管理工具的支持。定义配置项，变更过程。在传统的方法学中，文档，源代码和数据是配置管理的主要配置项，但在XP中，文档被最小化，测试程序和源代码，数据成为XP项目的主要配置项。在我们公司的模式下，文档被简化，主要的配置项是源代码。但存在着基于项目的版本控制，和基于产品的版本控制矛盾。基于项目，针对性强，项目变更容易控制；基于产品，产品易维护，成本低。基于我们公司项目的复杂性，应分而制之。对于内部项目
11、和研究性项目实施基于产品的控制，但对于OEM或已售项目应该实施基于项目的控制，以便可控相应客户反馈。配置管理应形成制度化，和标准化。五、 风险管理软件开发是一项困难的任务，在软件开发过程中，有着大量的事情可能发生错误。对风险采取主动策略是软件质量保证的积极活动。风险管理活动主要包括：风险识别，风险预测，风险缓解，监控和管理。风险识别是试图系统化的确定对项目计划，估算，进度，资源分配的威胁，通过识别风险，进而避免，控制风险。识别风险的一个方法是建立风险条目检查表。风险涉及：产品规模，商业影响，客户特征，过程定义，开发环境，新技术，人员经验。风险因素有：性能风险，成本风险，支持风险和进度风险。不论
12、项目的大小，都存在着各种不同的风险。因此，无论项目大小，都应实施风险管理。实施风险管理的简单过程是，首先进行风险识别，识别出项目可能的存在的风险；基于识别出的风险，对所有的风险进行预测，划分出风险的等级，按等级对风险制定缓解方案，实施监控和管理。我们公司的环境和现状，项目的风险主要来自产品工程和开发环境两个方面。需求，管理过程和方法是风险识别的主要参考点。项目管理层应有计划的进行风险管理，在系统架构设计时，风险管理应作为一个标准活动存在。在每个项目立项后应立即进行风险管理，六、 复审和评审在软件开发过程的里程碑前，都应对配置项进行复审和评审活动。通过复审的配置项是达到配置管理的基线要求。复审是
13、对软件元素或项目状态的评估，以确定与计划结果的差异和提出改进。评审是基于客观的标准包括详细的评估清单文档，对软件产品或过程的独立评估，以确定对标准，方针，规范说明和程序的依从。软件元素是在软件开发或维护期间的可交付的或过程中生成的或可获得的文档，它包括项目的各种文档，源代码，报告和数据。复审和评审是适用于与质量保证相关的目标的支撑，见表-1：目的主要过程评估管理复审，技术复审验证审查，走查确认测试依从性确认评审表-1实现质量目标的主要过程复审和评审过程内容主要包括：管理复审，技术复审，软件审查，走查和评审。这些活动的过程模板如下：1 目的2 过程概要3 相关责任人员4 输入5 输入标准6 流程
14、7 结束标准8 输出9 相关文档及结果报告不论是传统的开发方法学，还是XP，复审和评审都是项目管理和质量保证的重要活动。传统的管理，技术等复审，审查；XP的结对编程；传统的每个里程碑的评审，XP的测试先行，实现后的重构等活动的保证。在我们公司项目实施流程中，不存在实质的复审和评审活动。实施有效的复审和评审，首先是项管人员对复审和评审活动的理解；次之是软件系统架构对复审和评审活动的定义；第三，是复审和评审活动的实施的方法定义和标准，规约等的制定。七、 测试及缺陷跟踪在1979年，Glen Myers在他著作软件测试艺术中如下论述了软件测试：1 测试是一个为了发现错误而执行程序的过程。2 一个好的
15、测试案例是指很可能找到迄今为止尚未发现的错误的案例。3 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。单从软件测试角度看，这些观点无疑是正确的。但是在现实中，软件开发受时间，成本等因素制约，为了获取商业的利益，我们必须均衡时间，成本和收益。因此，我们可以给出下面的描述：1 测试是为了在被测试的元素进入下阶段之前尽可能的发现错误。2 一个有效的测试案例是指覆盖了一个被测试项的特性的案例。3 一个成功的测试是指覆盖了所有的被测试项的所有的特性的测试。可见，测试不再是为了发现错误而执行程序，在程序实现前，我们就已经开始测试测试文档，对文档进行验证和确认活动。在XP实践中，是编写测试程序，也就是先行测试，再实现；以程序适应测试。与测试同步的是缺陷跟踪。广义上为两类：在文档测试阶段为配置管理中的变更管理，在程序测试阶段为软件缺陷管理。在此，论述的是软件缺陷跟踪对已发现的缺陷进行管理和监控修复。缺陷跟踪包括：缺陷报告，缺陷修复，缺陷修复确认，与缺陷相关模块的回归测试，缺陷分析等活动。为了能合理的实施缺陷跟踪，一般企业需要制定相应的工作流程和控制标准。在我们公司有着相应的缺陷管理工具：Team Track，和制定与此相关的各项工作标准和流程规范。但在
