浅谈软件质量保证

浅谈软件质量保证（精选6篇）

浅谈软件质量保证 第1篇

浅谈软件质量保证

摘要：

Software Quality Assurance软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用

前言：

SQA的由来：随着第一个正式的质量保证和控制方案在1916年贝尔实验室的出现，整个制造业都认可了这一方案，时至今日每个公司都有其保证其产品质量的机制，公司对质量的保证也渐渐成为其核心的市场策略。对于软件开发来说，一个项目的主要内容是：成本、进度、质量。软件本身作为一种无形产品，其质量指的是：“系统,部件或者过程满足顾客或者用户需要或期望的程度”。在20世纪五六十年代，质量保证曾经只由程序员承担。而正规的软件质量保证标准首先在20世纪70年代初军方的软件合同中出现，此后迅速传遍整个商业世界。提出而随着市场化发展的成型，任何软件公司对自己产品的质量问题越来越关注，测试所花费的成本越来越多。在起初国外很多的大软件公司公司比如IBM、CA等，SQA的职责就是测试（主要是系统测试）。后来，由于缺乏有效的项目计划和项目管理，留给系统测试的时间很少。另外由于软件最终使用者的不专业性，需求变化太快，没有完整的需求文档，测试人员就只能根据自己的想象来测试。这样一来，测试就很难保障产品的质量，促进了事先预防的SQA职能的产生。随后随着软件开发模型的不断演化和发展CMM模型的出现，它引入了“全面质量管理”的思想，至此许多公司将SQA人员独立于项目组，以保证评价的客观性。专业的SQA人员应运而生。

简介：

软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。其根本目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。

SQA的基本目标：

1: 软件质量保证工作是有计划进行的。

2: 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。3: 将软件质量保证工作及结果通知给相关组别和个人。

4: 高级管理层接触到在项目内部不能解决的不符合类问题。

具体分析：

1：软件质量所包含的因素及软件质量评价标准：

软件质量包含的因素：正确性，可靠性，效率，完整性，可用性可维护

性，灵活性，可测试性，可移植性，可复用性，互操作性等等。

软件质量评价标准：质量需求准则，着眼点是是否满足用户的要求；质量设计准则，开发者在设计实现时是否按软件需求保证了质量。质量度量准则，为质量度量规定了一些检查项目。

从事专业SQA的人员所应具备的基本素质，工作中的基本职能及与其他相似职能的区别：

SQA人员所应具备的基本素质：

按照软件界已经达成的共识：影响软件项目进度、成本、质量的因素主要是 “人、过程、技术”。首先要明确的是这三个因素中，人是第一位的。SQA小组的成员首先应当时刻以客户的观点看待软件。从事SQA工作由于要按照相应的标准对专业的行为加以监管，深刻了解企业的工程，并具有一定的过程管理理论知识 对开发工作的基本情况了解，能够理解项目的活动，因此首先应具备较高的关于软件开发方面的知识；在工作中过程为中心：应当站在过程的角度来考虑问题，只要保证了过程，QA就尽到了责任；还应具有服务精神即为项目组服务，帮助项目组确保正确执行过程；另外应善于沟通，能够营造良好的气氛，避免其工作本身成为一种找茬活动。我所在的小组在课程实践过程中就出现过负责设计的同学对编码阶段的同学出现质疑，最终出现不愉快的事情。

工作中的基本职能以及于其他相似职能的区别：

要做好SQA工作首先应该明确SQA人员的职能以及与QC、SEPG的区别。QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者； SEPG：制定过程，实施过程改进；

而SQA人员的主要工作为审计过程的质量，是过程质量审计者，其基本职能为确保过程被正确执行。其本身并不参与过程的制定，A的职责就是确保过程的有效执行，监督项目按照过程进行项目活动；它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。

3：SQA活动：

软件质量保证由各种任务构成，这些任务分别与两种不同的参与者有关：做设计工作的软件工程师和SQA小组成员。

软件工程师通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来考虑质量问题（并完成软件质量保证和质量控制活动）

SQA小组成员的职责为辅助软件工程小组得到高质量的最终产品。其主要工作如下：

为项目准备SQA计划。该计划在制定项目计划实制定，由所以感兴趣的相关部门评审。该计划将控制由项目组和SQA小组执行的质量保证活动。在计划中应标识一下几点：需要进行的评价；需要进行的审计和评审；项目可用的标准；错误报告和跟踪的规程；由SQA小组产生的文档；为软件项目提供的反馈数量。另外还需明确最终审计的结果报告给谁。

参与开发该项目的软件过程描述。软件工程小组为要进行的工作选择一个过程。SQA将评审过程描述以保证该过程与组织政策，内部软件标准，外界所订标准（如ISO9001）以及软件项目计划的其他部分相符。

评审各项软件工程活动，对其是否符合定义好的软件过程进行核实。SQA小组识别记录和跟踪与过量的偏差，并对是否已经改正进行核实。

审计指定的软件工作产品，对其是否符合定义好的软件过程中的相应部分进行核实。SQA小组对选出的产品进行评审；识别，记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目管理者报告。在审计过程中。注意审计一定要有项目组人员陪同，双方要开诚布公，坦诚相对。审计的内容主要包括：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。

确保软件工作及工作产品中的偏差已被记录在案并根据预定规程进行处理。偏差可能出现在项目计划，过程描述，采用的标准或技术工作产品中。

记录所有不符合的部分并报告给高级管理者。对不符合的部分进行跟踪直至问题得到解决。

4：软件评审：软件评审是软件工程过程中的过滤器。评审被用于软件开发过程的多个不同的点上，起到发现错误和缺陷节日引发排错活动的作用。软件评审起到的作用是净化分析，设计和编码的软件工程活动。在课程实践过程中由于初始需求分析的不明确以及后来概要设计过程中关键点的遗漏所引发的错误曾经导致我们小组代码的两次大部分返工，现在看来在课程实践过程中没有进行软件评审所致

5：正式技术评审（FTR）

正式技术评审是一种由软件工程师和其他人进行的软件质量保障活动。

正式技术评审的目标是：发现功能、逻辑或实现的错误；证实经过评审的软件的确满足需求；保证软件的表示符合预定义的标准；得到一种一致的方式开发的软件；使项目更易管理。

评审会议一般由3-5人参加，不超过2小时，由评审主席、评审者和生产者参加，必须做出下列决定中的一个：工作产品可不可以不经修改而被接受；由于严重错误而否决工作产品；暂时接受工作产品。

评审总结报告和记录保存：评审会议结束时，生成一份评审问题列表，完成一份包括“评审什么？由谁评审？结论是什么？”的评审总结报告。

评审总结报告是项目历史记录的一部分，标识产品中存在问题的区域，作为行政条目检查表以指导生产者进行改正。

评审指导原则：评审产品，而不是评审生产者。注意客气地指出错误，气氛轻松；制定日程并且遵守日程；不要离题，限制争论和辩驳。有异议的问题不要争论但要记录在案；对各个问题都发表见解。问题解决应该放到评审会议之后进行；做书面笔记；限制参与者的人数并坚持事先做准备；为每个要评审的工作产品建立一个检查表。应为分析、设计、编码、测试文档都建立检查表。；为了让评审有效，为FTR分配资源和时间；为了提高效益对所有评审进行有意义的培训；评审以前所做的评审。

6结合课程实践浅谈自己的感受

下面我将结合课程的实践讲一讲个人对于软件质量保证的一些感受，首先说一说每个人所扮演的角色，负责编码的同学相当于软件工程师的角色，而负责需求分析及概要设计的同学责同时兼任了SQA小组成员的角色。在具体实现过程中，在需求分析阶段，通过需求调研我们小组大体明确了客户即TA对机动车违章管理系统的需求，但由于没有把需求调研的工作做到位，在完成需求分析的过程中，我们小组出现了一些问题，主要是对TA要求的理解出现了分歧。此时承担SQA小组责任的同学并没有严格要求自己进一步与TA沟通，解决理解上的分歧，而是个人主观的认为自己的理解就是对的。致使在具体实现时与初始需求出现了一些偏差。这个问题的发生，主要是因为承担需求分析的同学同时兼任SQA小组工作的原因，致使监督的客观性方面出现了问题。在概要设计阶段由于考虑到后期一些功能在后期具体实现中的困难，没有严格按照获取的需求进行设计，主要是出于实现难度的考虑草率的对本已获得的需求进行了一些修改致使本就出现变差的需求进一步打了折扣。在编码阶段针对出现问题时，更是仅仅是就问题而谈问题，把原始的计划放到了一边。回顾整个课程的过程：从在初始人员定位时并没有认识到SQA小组的重要性，因此并没有严格指定专人负责，只是在出现问题时才想到，而在明确两人兼任SQA小组工作后，也没有严格制定明确的计划，也没有正式的评审各项软件工程活动，仅仅是想到什么就说什么，不但造成了小组成员间的冲突，更是对问题的解决没有多大的帮助。而“软件工程师”即从事编码的同学虽然对软件本身进行了一些测试，修正了一些错误，改进了一些BUG，但这一切都是通过想当然去做的，并没有参考设计文档。结论：

无论何种软件只有在保证其质量的前提下才能体现出它的价值。软件质量保证则是保证软件质量的基石。而在软件质量保证的过程中，首先应该明确自己的定位，而后严格按照上面提出的步骤与方法去实现才能更好的完成SQA工作。这一切，都需要我们在今后的学习、工作中积极地去实践。

参考文献：

软件工程实践者的研究方法 Roger S.Pressman

软件质量保证 Schulmeyer,G.G

浅谈软件质量保证 第2篇

摘要：文章就软件工程的历史和发展现状做了介绍，分别从软件工程的技术和管理两方面进行了分析，指出了发展过程中存在的问题，并提出了相关的解决办法。文章最后以ISO-900为验证软件质量的基础，然后再结合最新的DOSE方法和SQMP方法，建立一套完整的有关质量模型的框架，并结合相关的应用例子对模型进行系统介绍。

关键词：软件工程;软件质量管理;质量模型;质量体系框架;软件开发工具

1研究的背景和方向

1.1研究背景分析

软件工程进入我国已经比较晚了，依照国际惯例，主要从两个方面来对软件工程进行系统的研究：1.1.1软件工程技术主要包含两个方面：一方面是软件工程化的开发方法;另一方面是对软件开发工具的研究和软件环境的研究。用于软件工程研究的技术主要包括软件是否可靠、软件的度量有多少和软件整体的复用性这三方面的内容。虽然软件工程技术传入我国比较晚，但是随着互联网在我国的普及，软件工程的技术在我国取得了突飞猛进的发展，到现在为止，我们的市场上出现了很多优秀的软件开发的方法和工具。现阶段用得比较多的是瀑布模型和快速原型法，这两种方法在我国国内和国外都发展得比较成熟了。最近几年，随着各种各样新的软件开发技术不断出现，一些新的开发软件技术的思想也越来越广泛地被运用到软件开发中去，现在大家比较熟悉的包括面向对象的软件工程方式和面向用户的软件开发技术，这给我们软件工程的研究开创了一个新的方向。1.1.2软件工程的另外一个方面的内容就是软件工程管理。这里面包含对质量、费用、配置和项目的日常管理。一般我们需要有专业的人员对各项管理费用进行精确的计算。在软件工程管理当中主要遇到的问题有：第一，对软件开发的成本进行合理的控制，因为只有这样才能够让软件开发的利润实现最大化;第二，对软件开发中的资源进行一定的控制，用较少的资源实现软件开发的目标是比较明智的做法;第三，对软件整体的质量进行控制，软件最后能不能被市场大众接受，主要是由它的质量来决定的;第四，开发进度的问题，有些软件技术虽然比较好，但是由于各种原因造成其开发进度一再被延缓，导致迟迟不能够上市。

1.2软件工程的研究方向

在我国软件技术不断发展的今天，国际计算机行业也在不断涌现出新的思想和新技术，它们的出现为我国软件工程的发展提供了可靠的理论基础。而要想让软件工程技术取得一个好的发展，那么从一开始我们就要站在一个比较高的起点上对它进行研究，这样才能够跟上甚至赶超国际软件技术工程的先进水平。本文从软件工程技术和软件工程管理两个方向对国际上软件技术的一些新发展进行研究。希望大家在看了这篇文章结合实际例子的分析之后能够寻求一套比较先进的系统开发手段和管理手段。目前来说，软件工程研究采用的方法主要是由ElvarJacobs等若干人发明的OOSE这一种方法，此方法的名称叫做“面向对象的软件工程”。这种方法是由国外传过来的，一开始还不太适应我国的`国情。而在稍加修改之后已经慢慢地能够适应我国软件质量的管理需要了。在下面的内容中会对OOSE这一面向对象的开发方法进行详细的介绍。

2建立软件质量体系的模型

2.1建立模型

通常情况下，软件质量的参考模型由三方面组成，主要包括SQMP、OOSE和ISO9000这三个方面，SQMP是建立这种模型的基本指导思想，它的全称叫做软件质量的管理方法。这种模型的建立中最重要的就是对软件质量的管理设立一个基本的目标，我们把它叫做需求的建立，任何一个软件质量控制的模型都是以全面满足用户的需求为其根本的目标的。但是软件质量控制的模型包括不同类型的结构，在实现方法和整体的着眼点上面有着本质的不同，所以我们在建立模型的过程中自然会对其具体的性能和功能提出不同的要求。从目前对软件工程性能的讨论中可以得知，只有能够很好地维护软件技术的软件质量控制模型才能够更好地被大家利用。此外，如果软件质量体系的模型开发的过程能够变得更简单和更容易被理解的话，那么应该可以被大家所接受。另外，越是高级的模型开发过程，它越是灵活，越是能够抵御各种各样的变化。这些软件质量体系开发的过程和模型建立的方法有着千丝万缕的联系。在SQMP模型开发的第二个方面中，重点指的是设计、开发和维护的相关方法。这种面向对象的开发方法，本身内部就有各种类型的思想，而且思想内部都有很多种不同类型的优秀品质，而OOSE这种软件开发的方法是以最终的维护为根本目的，所以在软件的开发和设计的过程中能够充分地把它的思想优势发挥出来，让整个模型的质量能够更上一层楼。

2.2质量体系的框架

这一节主要讲述了质量体系的框架建立过程中的基本原则、步骤、要素和要求，我们可以分七个方面来叙述：2.2.1确定正确的质量方针和目标。一个组织对质量的整体要求主要体现在它的质量方针内部，它是衡量职工行为准则的主要方法，也是确定整体质量工作的主要方向。在质量方针内部最核心的内容是质量目标，一个企业要想其核心产品的质量达标，那么就一定要设立相应的目标。2.2.2对整个组织机构进行确定。组织机构是保证一个企业能够正常运转的核心。我们一定要对企业内部的相关机构进行调整，然后才能够更好地适应其质量管理的相关要求。在软件技术和软件工程开发的过程中，我们一定要把具体的目标制定成详细的项目，然后再建立相应的责任小组对其进行管理。为了能够让整个项目正常运转，每一个组织机构的内部应该建立一个专门的质量管理部门，这样才能够让相关的人员更好地建立对应的质量体系，同时从事包括质量控制和质量实施等相关的活动。此外，为了能够对整体软件工程和软件项目的质量更好地进行监督，一个组织机构内部的质量部门应该是独立的，并且只对高级领导层和相关的机构进行负责，并不受其他部门和组织的约束。整个质量控制部门能够对生产过程中的各个环节进行严格的监督，如果一旦发现问题的话能够及时地予以解决。

2.2.3对组织内部的员工进行相关的教育和培训。如果组织的内部没有相关质量体系的规定，那么整个机构质量的控制应该由最高领导层和相关的机构进行负责。然后在这个过程中加紧进行质量管理部门的建设，并对全体的员工进行质量管理知识的培训和学习，这样才能够使整体员工的质量意识得以提升。整个质量管理部门一定要熟悉整个质量管理的方法，并明确内部的责任和相关的分工，以求让整个质量体系能够快速高效地实施。具体的步骤包括以下三步：第一，先由整个质量管理部门中的管理角色制定出具体的质量管理计划，并与其他角色进行协商，把整体计划中的不合理因素去除掉;第二，对软件质量开发中的开发层和管理层进行相关概念的教育，目的是为了让每一个开发者和管理人员都能够更好地明确自身的责任，让他们明白质量管理在整个机构开发中的重要性;第三，每个企业都应该制定符合自己发展状况的质量手册，并分发给每个人，这样大家在工作中才能够对自己岗位的职责、行为规范和质量要求等方面有清晰的认识。

2.2.4明确管理岗位的职责。在建立相关的软件技术组织的基础上，应该明确整个质量体系监督的过程中每个部门和每个人员的职责和他们相互之间的关系。这些责任主要包括企业的责任、项目管理负责人的责任、各个机构的基本责任、客户的责任、整体工程需求的分析、整体工程的开发、整个工程目标的实现和各环节的测试等，只有明确各方的关系，才能够对软件开发过程质量控制中的每个环节进行明确，在管理的过程中做到既没有责任的重叠，也不会出现管理过程中职责的疏漏。而如果软件技术的质量控制中出现任何问题或者缺陷，我们也有依据进行追查和寻找。

2.2.5评审过程。为了能够更好地对软件工程中的质量体系进行相关的审核，应该组织专门的人员和机构来进行评审，以方便内部的质量体系能够不断地被改进。软件技术的质量审核主要包括内部审核和外部审核两个部分。内部审核主要包括对企业内部的负责人进行管理和培训，审核前应该按照相关的需要对审核的程序进行安排，然后书面记录相关审核的结果，如果发现任何问题应该及时采取措施去纠正。外部审核包括由外面聘请来的专家对整个软件技术的质量进行审核。

2.2.6与质量体系相关的文件。在确定质量体系的过程中，要把其内部的所有规定都变成文字记录下来。为了让人更清楚地明白整个质量体系的内容，文件中的内容应该包括质量体系要素、质量体系要求和相关的预防措施，并变成相关的规定。在进行软件项目的开发和实施的过程中，应该依据质量体系文件中的相关规定进行操作，最终形成有关质量活动的计划并做成文件，以确保相关的人员都能够按照上面的要求来执行。

2.2.7相关纠正措施。制定相关的措施对质量体系管理中的相关不良规定进行纠正，并监督人员贯彻执行。纠正措施的内容主要包括：第一，调查软件和产品不合格的原因并做相关的分析，为防止再次发生此类问题制定相应的措施;第二，对质量控制体系中的整体过程、操作要点、质量记录、服务内容报告和顾客的投诉情况进行相应的分析，对于可能会产生不合格品的潜在原因进行研究;第三，根据产品产生质量问题的风险程度提前采取相应的预防措施，并在操作的过程中对预防措施进行相应的改进;第四，更改相关的措施规程，并进行详细的记录。

3结语

本文先对软件工程的相关发展状况进行了系统的分析，然后提出了针对软件工程的一些基本认识，在此基础上运用最先进的软件工程开发知识和相应的管理成果最终形成一种实用、有益于软件质量提高和能够大幅度提高软件生产效率的开发方法，并形成一个专业的质量体系框架模型。由于软件开发的局限性，以上的观点还有很多不完善的地方。软件工程和软件质量管理中的很多问题还没有来得及深入地进行探讨。而且只有在实践中进行方法的积累才能够得出大量的数据和经验，单纯从理论上进行分析是不够的。也欢迎大家对本文的相关观点提出自己的见解，希望能够对大家提供帮助。

参考文献

[1]纪新.转型期大型企业集团档案管理模式研究[D].天津师范大学，.

浅谈软件质量保证 第3篇

一、酒店硬件设施建设

酒店内的硬件水平是顾客评价该酒店服务质量好坏重要的物质基础和组成部分, 硬件设施必须在酒店开业之前经过细心地设计与规划, 结合人文精神, 讲究主题, 提高酒店的文化内涵。

第一是建筑设计。酒店行业的建筑风格、设施的装饰、总体亮化工程都要与酒店的档次协调一致, 这是酒店向顾客提供服务的物质基础。酒店的地理位置、外部装饰等硬件设施的完备和完好程度如何, 都直接影响到顾客的需求质量和消费层次。如五星级的酒店总是在外部建筑设计上给人以磅礴的气势, 加之知名品牌为其装裱上的光环, 便利的交通环境, 所以宾客络绎不绝便不足为奇了。

第二是内部环境。酒店内的灯光、色彩应该柔和, 例如以橙色为代表的活力色彩, 可以诱发客人食欲, 创造温馨环境, 与整体用餐环境协调, 增进顾客的舒适感和愉悦感。作为餐饮设施的家具、餐具也必须要配套, 增添一些和企业文化相匹配的陶瓷、壁画, 与整体环境相映成趣。特别是酒水器皿不仅要清洁卫生, 还要与菜品、酒水的品种相般配。酒店内的环境影响是综合的, 好的装修装饰设计、绿色植物刻画出的自然气息、饮食烹饪过程中产生的美味、怡人的餐饮环境, 就能使该酒店的竞争能力发挥到极致。

第三是特色配套设施。独具特色的配套设施会给酒店的服务加上闪亮的一笔。美国喜达屋酒店管理公司旗下的威斯汀商务酒店, 以它独具匠心的“天梦之床”号召于众, 具有好奇心理的商务型宾客自然会选择在该酒店入住。又如希尔顿酒店开通了天然温泉桑拿房, 将温泉活水从几百公里外的山涧温泉水运输到酒店的最高楼层, 尊荣、奢华的享受吸引着高消费需求的宾客, 特色配套设施均以满足顾客特殊需求为目标, 打造高端客户市场。

二、酒店软件服务

酒店内的软件服务水平是无形的产品, 只有宾客入驻到该酒店消费时才能感受到该服务的存在。作为酒店业的经理人, 必须在日常的运营管理中加强软件服务体系的建设, 提高酒店的综合服务水平, 避免人为的差错导致服务质量问题的产生。酒店内的软件大致分为以下几点:

第一是员工素质。由于酒店服务工作是员工与顾客直接打交道, 面对面的服务是它的主要形式, 因此员工的基本素质对服务质量也有着很大的影响。酒店业经营成功与否, 在硬件建设完成之后, 就取决于酒店的员工。酒店在确定自己的经营定位及场地的布局后就应该制订出一套适合本酒店的人力资源管理系统。除了制订出酒店服务标准和规范, 使服务工作有章可循, 还应该强化员工的培训教育工作, 通过“性格特征应聘法”的用人计划, 对各岗位人员有目的地去选择和利用, 增强员工的团队意识、责任意识、职业道德, 提高员工整体的素质水平。

第二是服务方法。它包括服务技能、服务方式、服务程序、服务的艺术以及管理体制的各种方法。酒店服务人员要牢记服务行业工作人员的“应知应会”, 树立主人翁意识, 从真正意义上去了解宾客, 真诚地对待每一位宾客, 充分体现对宾客的关爱。提供个性化服务, 急顾客之所急, 想顾客之所想, 尊重客人、了解顾客、以特色服务来体现服务档次, 以创新带给宾客“心动”的感受, 体现温馨及宾至如归的服务。

第三是服务质量管理体系。质量是所有企业永恒的主题, 质量管理也更是全员参加的管理。当今, 众多酒店行业为了健全质量体系, 均做了ISO9001质量体系认证, 以国标体系追求完美的服务质量。管理的目的就是使全体员工在服务的过程中形成一种共识, 服务的投诉率哪怕只有千分之一, 但是对于宾客来说就有可能是百分之百, 使顾客摇头, 下次不再光临。服务质量是酒店行业的生命, 酒店管理者必须自始至终狠抓不放, 才能让酒店赢得市场、赢得效益。

第四是企业文化和发展理念。一个优秀的酒店必须要有自己内部新颖、健康的企业文化和发展理念。香格里拉酒店是国内知名的酒店品牌, 他们的服务标语是:真诚质朴、彬彬有礼、温良谦恭、乐于助人、让宾客喜出望外。所有的员工每天例会前必须要大声喊出酒店的服务标语, 将酒店的企业文化深入人心, 服务人员将“好客之道”作为追求的目标。正是因为这种企业文化, 才使得酒店拥有了强大的精神凝聚力, 员工的队伍极其稳定, 避免了因为员工的流失和人心不齐导致的服务质量的下滑。

三、结语

浅谈现代软件质量标准与测试技术 第4篇

关键词:软件测试;静态测试;动态测试;黑盒测试;白盒测试

中图分类号:TP306 文献标识码:A 文章编号:1674-7712 (2012) 12-0062-01

随着计算机技术在各个领域中的广泛使用,软件重要性越来越显突出,人们在享受软件产品带来的便利的同时,也重点关注软件产品的质量。对那些质量不合格的软件产品给开发商和用户都带来麻烦,而在一些关键部门的应用,如果出现质量问题则是毁灭性的。因此加强软件测试是提高软件保证的关键。

一、现代软件质量标准

尽管软件的质量难以量化评估,但也有公认的质量标准,目前通行的国际标准是ISO 9126,该标准从6个方面(质量特性)来对软件进行细化定性评估,详见下表。

二、现代软件测试的分类

毫无疑问,软件测试具有非常重要的作用,这一点,在找出软件中的错误和缺陷时进行严格评审和详细测试仍然是主要手段。软件测试分类见下表。

三、常用现代软件测试技术简述

(一)静态测试

静态测试是指被测软件的目标程序不在计算机上执行,通常需求分析阶段即可开始,它对发现软件错误和缺陷的贡献率很大,错误和缺陷越发现得早,所花的成本越低。静态测试(各阶段)内容与测试工具见下表。

(二)动态测试

动态测试是被测软件的目标程序在直接计算机上执行。动态测试(各阶段)内容与测试工具见下表。

(三)黑盒测试

黑盒测试包括:

(四)白盒测试

(五)其他软件测试技术

除了前面4种常见测试技术,以下测试(调试)技术也经常被使用:

1.逐句执行技术。

2.多余物寻找/删除技术(特别是资源有限时需要进行,也可静态进行)。

3.软件执行状态动态显示技术。

4.运行错误/故障的定位和修复技术。

四、结语

为了开发出高质量的软件,进行软件测试是重要的手段。通过测试,其中的错误可以发现,但是想要证明错误已不存在,却无法实现,因此,软件测试具有一定的狭隘性,为了能够保证软件的正确与高质量,必须在软件测试的基础上,进行全方位综合性的软件质量把关。也就是说,我们需要本着现代软件工程的理念,从技术与理论、环境与工具、控制与管理、规范与标准等四个方面全面实施软件工程。

参考文献:

[1]朱少民.全程软件测试[M].北京:电子工业出版社,2007

[2]董晓霞.软件测试工程化的研究与实践[J].计算机工程与设计,2006,27(11)

[3]朱少民.软件测试[M].北京:人民邮电出版社,2009

软件质量保证管理 第5篇

左边是设计和分析，是软件设计实现的过程，同时伴随着质量保证活动---审核过程，也就是静态的测试过程；右边是对左边结果的验证，是动态的过程，即对设计和分析的结果进行测试，以确认是否满足用户的需求。V模型避免了瀑布模型所带来的误区-----软件测试是在代码完成之后进行的。p302、什么是变更控制？（P111）

软件开发过程中都会产生许多变更，如配置项，配置，基线，构建的版本，发布的版本的变更，对于这些变更，都要有一个控制机构，以保证所有的变更都是可控的，可跟踪的，可重现的。这样的一类机构对变更的管理，就是变更控制。

3、软件可靠性概念？（P176）

软件可靠性是指在给定时间内，特定环境下软件无错运行的概率，软件可靠性包含了以下三个要素：规定的时间，规定的环境条件，规定的功能。

4、CMM（P195）

CMM：能力成熟度模型，用来衡量组织软件过程成熟度和评价其软件过程能力。能力成熟度是指一个特定过程被明确定义，管理，测量，控制并且是有效的程度。分为五个等级： 初始级 软件过程的特点是无序的，甚至是混乱的。几乎没有什么过程是进过定义的。可重复级 关键过程区域集中关注软件项目所关心的，与建立基本项目管理控制有关的事情。

已定义级 将软件生命周期的各个阶段严格的划分出来，从组织这个层次来保证过程质量该进

已管理级 软件产品的质量目标被量化管理，它遵循了全面质量管理活动的科学程序，关键过程域的关注焦点是建立起对软件过程和正在构造的软件工作产品的定量了解。

优化级 关键过程域包括那些为了实施连续不断的和可测的软件过程改进，组织和项目都必须解决的问题。

5、TQM的实施步骤（P265）

（1）建立质量小组，负责过程改进，流程完善，不断发现质量问题提出并实施解决方案。

（2）进行TQM思想的教育，通过教育，要让每个员工深刻认识到“满足顾客的需求是第一的”的思想，理解“什么是顾客需求”，如何让顾客满意等内容。

（3）了解市场，明确顾客需求，了解目前研发的软件产品的市场，包括竞争对手，客户群等，让员工明白什么是质量好的软件产品或软件服务，认真对待质量要求，开发出合格的产品。

（4）建立明确的质量基准和质量评估机制，以便和实际质量水平进行对比，识别质量的目标和工作的重点区域，采取相应措施。

（5）建立相对完善的奖励机制，在认可和给予奖励的过程中，应力求公正，真实，选择恰当的时间，恰当的场合，恰当的方式。

2、版本控制的目的:是在于对软件开发过程中文件或目录的发展过程提供有效的追踪手段，保证在需要时找到旧的版本，避免文件的丢失，修改文件的丢失和相互覆盖，通过对版本库的访问控制避免未经授权访问和修改。另外软件的控制是实现团队开发，提高效率的基础。

3、PDCA包括4个部分：计划、执行、检查、行动描述总结

(1)计划计划：就是分析当前状况，发现问题，找出原因和主要原因，制定质量方针、质量

目标、质量计划书和管理原则。管理原则有：过程方法、管理的系统方法、持续改进

(2)执行：执行时计划的履行和实现，主要按计划实施地去做，去落实具体对策，并实施过

程的监控，使活动按预期设想前进，最终达到计划设定的目标。

(3)检查：是对执行后效果的评估。检查是伴随着实施过程自始至终的，不断收集数据、信

息获取的过程，并通过数据分析、结果度量来完成检查。

行动：重点在于检查完结果，要采取措施，即总结成功的经验，吸取失败的教训，实施标准化，以后依据标准执行。

4、阶段性开发模型：增量模型和迭代模型

(1)增量模型描述软件产品的不同阶段是按产品所具有的功能进行划分的，先开发主要

功能或用户最需要的功能，然后随着时间的推进，不断增 加新的辅助功能或次要功能，最终开发出一个功能完善的，稳定的产品。

(2)迭代模型描述软件产品的不同阶段是按产品深度或细化程度来划分，先将产品的整个框架都建立起来，在系统的初期，已经具有用户所需要的全部功能。然后随着时间推进,不断细化已具有的功能或完善已具有的功能,这个过程是一个迭代的过程

6、零缺陷质量管理的实施步骤：（P268）

（1）建立推行零缺陷质量管理的组织事情的推行都需要组织的保证，通过建立组织，可以动员和组织全体职工积极的投入零缺陷管理，提高他们参与管理的自觉性也可以对每个人的合理化建议进行统计分析，不断进行经验交流，公司的最高管理者要亲自参加，表明决心，做出表率，要任命相应的领导人，建立相应的制度，要教育和训练员工

（2）确定零缺陷管理的目标，确定零缺陷小组在一定时期内所要达到的具体要求，包括确定目标项目，评价标准和目标值

（3）进行绩效评价，（4）建立相应的提案机制

（5）建立表彰制度

SQA组织的责任是审计软件经理和软件工程组的质量活动中出现的偏差。

7、SQA计划（P283）

SQA在项目早期要根据项目计划制定与其相应的SQA计划，定义各阶段的检查点。标识出检查审计的工作产品对象，以及在每个阶段SQA的输出产品。具体实施步骤如下：

（1）了解项目的需求，明确项目SQA计划的要求和范围

（2）选择SQA任务

（3）估计SQA的工作量和资源

（4）安排SQA任务和日程

（5）形成SQA计划

（6）协商，评审SQA计划

（7）批准SQA计划

（8）执行SQA计划

SQA计划包含以下内容：

（1）目的，SQA计划的目的和范围（2）参考文件，该SQA计划参考的文件列表（3）管理，组织，任务，责任（4）文档，列出所有的相关文档，如程序员手册，测试计划，配置管理计划等（5）标准定义，文档标准，逻辑结构标准，代码编写标准，注释标准等（6）评审/审核（7）配置管理，配置定义，配置控制，配置评审（8）问题报告和处理（9）工具，技术，方法（10）代码控制（11）事故/灾难控制，包括火灾，水灾，紧急情况等。

8、评审和审核的区别？（P285）

评审：过程进行时，SQA对过程的检查，SQA的角色在于确保当执行工程活动时，各项计划所规定的过程得到遵循，评审通常通过评委会的的方式进行，是对工作流程的评审

审核：在软件工作产品生成时，SQA对工作产品进行的检查，SQA的角色在于确保开发工作产品中各项计划所规定的过程得到遵循，审核通常通过对工作产品的审查来执行。侧重于产品本身。

SQA报告应遵循三条原则SQA和高级管理者之间应有的沟通渠道，SQA报告必须发布给软件工程组织但不必发布给项目管理人员，在可能的情况下向关心软件质量的人发布。

SQA度量是记录花费在SQA活动时间人力数据。涉及以下三方面：软件产品评估度量、软件产品质量度量、软件过程审核度量。

SQA的评估任务是软件开发前期对目标的软件和硬件资源进行评估，以确保其充分性和适合性。

9、白盒测试、黑盒测试（P390）

白盒测试将被测试程序看做一个盒子，测试者能够看到被测程序，可以分析被测程序的内部结构。

白盒测试可以用来对代码结构进行全面测试，常用的有语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，条件组合覆盖，路径覆盖，循环测试

黑盒测试常用来验证软件或模块功能是否得到实现，主要运用单元的性能和功能方面的测试除了测试其功能外，还需确保代码在结构上可靠，健全并能够有良好的响应。黑盒测试主要运用于单元的功能和性能方面的测试。功能测试包括用户界面测试各种操作的测试不同的数据输入逻辑思路，数据输出和存储的测试。

区别：关键区别应该就是测试对象不一样，白盒测试主要针对的是程序代码逻辑，黑盒测试主要针对的是程序所展现给用户的功能，简单的说就是前者测试后台程序后者测试前台展示功能

10、测试的原则概括为10项：

（1）所有测试的标准都是建立在用户需求之上2软件测试必须基于“质量第一”的思想去开展各项工作3实现定义好产品的质量标准4软件项目一启动。软件测试也就是开始5穷举测试是不可能的6第三方进行测试会更客观，更有效7软件测试计划是做好软件测试工作的前提8测试用例的设计出来的，不是写出来的9不可将测试用例置之度外，排除随意性10对发现错误较多的程序段，应进行更深入的测试

39、功能测试的概念：是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否能正常使用、是否实现了产品规格说明书要求、是否能适当地接收输入数据而产生正确的输出结果等。

5、风险管理法：SEI（软件工程研究所）风险控制一般分5个步骤：P80

(1)风险识别：试图系统化的方法来确定威胁项目计划的因素。识别方法包括：风险检

测表、头脑风暴会议、流程图分析、与项目人员面谈。

(2)风险分析：可以分为定性风险分析和定量风险分析。定性风险分析是评估已经识别

风险的影响和可能性的过程。定量风险分析是量化分析每一风险的概率及其对项目目标造成的后果，同时也要分析项目总体风险的程度。

(3)风险计划：制定风险行动计划，应考虑以下部分：责任、资源、时间、活动、应对

措施、结果、负责人。

(4)风险控制：方法：风险避免、风险弱化、风险承担、风险转移。

(5)风险跟踪：监视风险的状况，检查风险的对策是否有效、跟踪机制是否在运行，不

断识别新的风险并制定对策。

6、评审的内容：分为管理评审、技术评审、文档评审、过程评审（P217简答）

(1)管理评审是以实施质量方针和目标的质量体系的适应性和有效性为评论基准,对体系文

件的适应性和质量活动的有效性进行评价。目标：按规定的时间间隔对质量体系进行评审，确保持续的适宜性和有效性，以满足本标准要求和提供的质量方针和目标。输入：体系审核的结果。输出：《管理评审报表》

(2)技术评审是对产品以及各阶段的输出内容进行评估。目的：确保需求说明、设计说明书

与最初的说明书保持一致，并按照计划对软件进行了正确的开发。输入：需求文档、源代码、测试用例、评审检查单、其它文档。输出：技术评审报告

(3)文档评审分为格式评审和内容评审。

(4)过程评审是对软件开发过程的评审，其主要任务是通过对流程的监控，保证SQA组织

定义的软件过程在项目中得到了遵循，同时保证质量方针能得到更快更好的执行。

40.朱兰三部曲：

质量策划：为建立有能力满足质量标准化的工作程序，质量策划是必要的质量控制：为了掌握何时采取必要措施纠正质量问题就必须实施质量控制

质量改进：质量改进有助于发现更好的管理工作方式

40、从软件开发的各阶段论述如何提高软件产品的质量？

1、需求

我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。如果对UML比较熟悉的话，需求分析可以利用UML工具进行，这样可以减少一些自然语言引起的歧义，但是UML可能与用户沟通起来有一些障碍，因为并不是所有的用户都了解UML各种图形的意思。除了工具之外，我们可以从以下几个方面来保证需求描述的质量。

1、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。

2、句子是否有语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。

3、是否存在模糊不清的需求，出现类似于可能，大概，或者等词汇表述的需求。

4、另外注意引用的术语和词汇是否前后一致。

5、是否存在一些形容词、比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围，要不然不同的人根据不同的理解就会得出不同的结果，最终可能跟用户最初的要求有偏差，那“炒回锅肉”的事情就不可避免地会发生。

另外保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化也会很容易造成代码的返工，于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。那么我们怎样才能判断需求细化的程度呢?需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢?哪些需求又太粗了呢?答案是需求是否可以写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要再进行细化。

2、设计

软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也不相同。例如用户关心的是需求，因此我们的设计对需求的覆盖率是多少?对于程序员来说模块是否清晰，类的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。对于维护人员来讲系统的扩展性、可维护性如何?一个高质量的软件架构，应该最大限度的考虑并满足不同角色的不同要求。正

是因为有这些要求，我们在进行软件设计的时候，应该进行全面的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考虑：

1)、功能性：包括完全性、正确性、安全性、兼容性、互用性。完全性包括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。正确性包括需求一致度。安全性根据软件需求的不同有不同的安全性要求。

2)、效率：包括产品运行的时间效率和利用的硬件资源两方面来考虑。

3)维护性：包括架构的可改正性，可扩充性以及可测试性。如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。

4)可移植性：包括硬件的独立性、软件独立性、可安装性、可重用性。软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。

5)可靠性：包括缺陷数量、容错性、可用性。

6)使用性：包括可理解性、易学习性、可操作性、易沟通性。我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此在软件的可使用性也是非常重要的。

3、编码

代码质量的一个很重要的标准就是代码的可读性及规范性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也就是最容易出现缺陷和错误的地方。类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个导入类发生变化都会影响到该类本身，另外如果该类的public方法太多也会导致类之间的高耦合性增加。

也许有的程序员会认为写出可读、规范的代码会影响工作进度。的确，对于程序员个体短时间来说为代码写上注释是要花费些时间，但如今软件开发是多人协作

周期很长的过程，写过程序的人都知道，如果自己写了不规范的代码，随着自己所写的代码越来越多，到后来需要修改某个前期写的模块时都不知道自己当初是怎么想的了，读自己的代码也需要花很长时间才读懂。况且如果随着人员的调动等其他原因，往往维护代码的程序员已不是当初写代码的人，很多情况就是读懂了一段糟糕的代码还比重新写出一段代码花费的时间还长，严重影响工作效率(有些时候还影响维护人员的心情)，反过来，如果大家都讲究把代码写成规范可读的，无疑对于整个组织来说提高总体工作效率是非常有用的。

代码质量另一个非常重要的衡量手段就是测试，通过统计测试代码所产生的缺陷情况，如严重等级分布、缺陷曲线的变化等可以从一个方面来简单地评估代码质量。

4、测试

测试人员在测试过程中，需要站在不同的利益相关者的角度，对测试对象的质量进行检查和验证，例如：测试人员除了关注需求文档中明确描述的需求条目之外，还应该关注隐现的需求，比如：竞争对手的产品特征、用户的群体特征和使用习惯等。因此，在测试过程中，测试人员除了关注测试对象的功能测试之外，还需要针对其他非功能特性进行测试。

软件质量保证模型探析 第6篇

软件质量保证模型探析

【摘要】本论文针对软件质量体系及保证模型中的相关问题进行一些有益的探索，力图通过对相关模型的比较研究，寻求到能够全面反映和保证软件质量的保证模型。在软件组织中，可以将ISO和CMM结合起来应用，即：把ISO作为软件质量管理的指导性框架，把CMM作为具体实施层的应用，这样就可以充分利用二者的优势来共同完成对软件开发过程的质量控制，从而达到既提高软件开发效率又保证所开发的软件具有较高的质量。 【关键词】能力成熟度模型;软件生命周期;软件质量保证 目前，软件企业面临的最大的问题是顾客对产品不满意，究其原因，软件质量保证技术的不完善是主要原因之一。就整体而言，我国的软件质量管理和质量保证工作仍处于创建阶段，国外的软件质量管理和质量保证工作也不尽完善，现有的软件质量保证是在软件开发过程中的每一步都进行“保护性活动”。主要内容包括对方法和工具应用的规程、技术复审、测试策略、保证与标准符合的规程，以及度量和报告机制。在技术上的主要手段是测试和复审，在管理上的主要手段是ISO9001的认证[1]。ISO9001是一种“静态”的质量保证标准，只规范了质量体系的最低可接受水平，并不描述一个组织如何实现这些系统质量要素来满足顾客的需求;CMM是一个致力于组织过程改进的框架，问题是并未提供有关实现关键过程域所需要的具体知识和技能[2]，在一定程度上造成了开发过程的僵化，对于当前软件业来说也是很难实现的。 一、ISO9001与CMM的联系 CMM和ISO9001都涉及质量管理和过程管理，并且都受到类似的利害关系驱动，两者之间的相似之处总结为以下四点： (1)它们的`精神一致，都有一个基本思想：“言所行，行所言”; (2)二者都强调管理、过程、规范化和文档化; (3)ISO9001与CMM的出发点都是通过对生产过程进行管理来确保产品的质量; (4)都源自以戴明为首的管理专家的制度管理思想。 首先，不管是CMM还是ISO9001都强调对产生应用软件之过程的管理，提高软件产品的生产效率和软件的质量，同时，软件工程理论的广泛运用也推动了软件产业由小规模生产到集成自动化生产迈进。这也充分说明，软件产品的质量不仅表现在最终产品的质量，还应该包含软件产生过程的质量，只有这样，才能使软件组织连续不断地生产出高质量的软件产品。 此外，CMM和ISO9001并不是孤立或彼此矛盾的。它们的核心思想都来源于埃华茨・丹明和约瑟夫・佐兰提出的全面质量管理思想，这种质量管理思想强调预防，而不是检修缺陷与错误改正。因此，它们之间的结合在理论上是可能的。ISO9001的每一个质量要素都可以对应到CMM2―3级中关键过程区域的特征上。而CMM在生产过程中的管理重点，又弥补了ISO9001在微观管理上的不足。另外ISO9001：版中增加的度量正好是CMM第四级强调的重点。 二、ISO9001与CMM的区别 (一)保证质量的方式不同 ISO9001作为质量保证标准，只论述了质量体系的最小需求，即合格质量体系的最低可接受水平。它是一种“静态”标准，企业只要符合它要求的条件并通过权威机构的审核，就可以通过认证，证明企业的内部管理已经达到一定水平，符合该标准规范的要求。而CMM则强调过程控制、过程管理、持续的过程改进。CMM不仅仅是对产品质量的认证，更是一种改善软件过程的模型，它以一种结构化的成熟度框架描述了软件管理和工程实践，指出了软件过程不断改进的科学途径[3]。它所定义的5个级别就像5个台阶，企业必须一步一步地“攀登”。每一个成熟度级别，既是企业发展的阶段性目标，又是评价企业能力水平的一个标准。当通过某一级CMM评估后，企业还必须持续不断地改进过程，其目标是要达到可持续发展、可优化的程度，以此来实现高质量、高效率、低成本的生产软件。因此，可以认为CMM是一个“动态”模型。 需要强调的是，ISO9001着重于考核产品的质量和产品过程的受控状态，给企业提供一种PASS/FAIL的检查体系，即企业的过程能力只有两种状态，虽然在缺陷预防和内审管理中涉及到了过程改进，但是并没有对改进的目标和方法进行指导和控制。CMM则重点考核软件组织的工程能力，而且突出不断改进、升级的要求。显然过程不断的改进、能力不断的增强，新技术的应用就会收到更好与更快的成效，产品的质量就会不断的得到提高和保障。 (二)认证审核过程不同 ISO的认证过程分为两个情况――机构或者通过了ISO认证，或者没有。如果机构通过了ISO认证，其过程已满足ISO9000的标准要求。与此不同的是，CMM给出的是过程改进的体系。CMM将软件过程划分成5个成熟度级别――从原始级(第一级)到优化级(第五级)。软件机构可处在其中的任何一个级别，它的每一级对所要实现的关键过程域都有详细的要求，并且强制企业能自我更新和持续改进，以实现缺陷预防[4]。这对于提高软件企业自身质量管理素质是非常有利的。 但CMM毕竟是一个在学术报告基础上建立起来的一套评估体系，它的认证结果是由SEI授权的首席评估员寄一封带有本人签名的信给被评估者，并在SEI备案，没有任何证书，终生受用，中间不再审查。而通过ISO9000认证的企业，要在中国技术监督局备案，并且发证给企业，并要求每年审查，所有参加多边认可协议的国家必须认可，适用性强。 (三)适用范围不同 ISO9001标准是一个适用于提供各种产品/服务企业的通用型的企业标准，而且主要是针对制造业制定的[5]。正是由于ISO9001的通用性，使得它无法满足软件企业更深层次的专业化管理需求。而CMM是专门针对软件开发企业设计的，可以帮助软件企业有效地管理软件过程。 ISO是通用的，并且是从客户和外部审计者的角度来写的，它提出的是最基本的要求，所以不是十分具体。而CMM是面向软件的，即面向软件开发人员的，它提供了机构内部过程改进的指南，而且CMM对每个级别的关键过程域都有很详细的说明，光CMM的关键实现的说明就有500页之多。 (四)管理层次不同 从管理层次上看，ISO要比CMM所处的级别高，ISO只是提出了一个质量管理框架，是属于指导性的框架，而CMM提出的框架是一个操作性很强的框架，其KPA过程非常明确地提出了过程目标和过程注意事项。 三、相关建议 在软件组织中，可以将ISO和CMM结合起来应用，即：把ISO作为软件质量管理的指导性框架，把CMM作为具体实施层的应用，这样就可以充分利用二者的优势来共同完成对软件开发过程的质量控制，从而达到既提高软件开发效率又保证所开发的软件具有较高的质量。我国中小软件企业在建立软件质量保证模型时，应该考虑以下几个方面的因素： (1)某种程度上市场目标决定质量目标，只有能满足客户需求的软件才可以称为好的软件。 (2)在考虑最终软件成品的同时，要考虑软件过程的质量保证。 (3)全面质量管理及CMM思想的集成，要关注软件过程控制能力以及过程持续改进能力。 参考文献 [1]李娟.基于QFD的软件质量保证模型研究[D].西北工业大学，. [2]李娟.CMM实施过程模型及实例化方法研究[D].中国科学院软件研究所，. [3]叶俊勇，汪同庆等.软件开发的质量保证体系[J].计算机与现代化，，6：27-32.