软件评测师笔记_软件质量管理基础20161022

软件质量管理

软件是逻辑产品，其质量属性有不一样的特色。软件质量保证（SQA）活动是确保软件产品在软件生存期全部阶段的质量的活动，即为了肯定、达到和维护须要的软件质量而进行的全部有计划、有系统的管理活动。

 

归纳地说，软件质量就是软件与明确地和隐含地定义的需求相一致的程度。具体地说，软件质量是软件与明确叙述的功能和性能需求、文档中明确描述的开发标准，以及任何专业开发的软件产品都应该具备的隐含特征相一致的程度。

软件质量具备如下3个要点。

（1）用户需求是衡量软件质量的基础，与需求不一致就无质量可言。

（2）指定的开发标准定义了一组指导软件开发的准则。若是没有遵照这些准则，确定会致使软件质量不高。

（3）一般还有一些没有明确写进用户需求说明书但开发人员都应当了解的隐含需求（例如易理解性、易修改性等）。若是软件仅知足明确描述的需求，但不知足这些隐含的需求，那么软件的质量仍然是值得怀疑的。

计算机软件是一种复杂、抽象的逻辑实体，它所固有的一些特色包括抽象性、复杂性、多样性、易变性、软件开发需求难于把握等。全部这些软件独具的特色都增长了软件开发的困难。

影响软件质量的因素主要包括：

（1）人的因素。

（2）软件需求。

（3）质量问题可能出如今开发过程的各个环节上。

（4）测试的局限性。

（5）质量管理的困难。

（6）质量管理未能给予足够的重视。

（7）软件人员的传统习惯。

（8）开发规范。

（9）开发工具的支持不够。

软件质量可用多种软件质量模型来描述。《GB/T 16260.1—2003信息技术 软件工程 产品质量 第1部分：质量模型》分别给出了软件内部质量（Software Internal Quality）、软件外部质量（Software External Quality）和软件使用质量（Software Quality in Use）的概念和模型，质量模型由3个层次组成：质量特性（Quality Characteristics）、质量子特性（Quality Subcharacteristics）和度量（Metrics）。

 

1．质量需求分析

质量需求分析就是肯定与软件项目相关的质量目标和标准。根据项目需求肯定质量目标、标准、级别和评判标准，并将其做为检验质量成果的基础。在肯定质量需求时，特别在资源有限的环境中，要考虑到质量目标的优先级，以及品质、性能、费用和时间等影响客户满意度的要素间的平衡。

2．质量计划

质量计划就是为肯定如何知足质量需求分析中制订的质量目标和标准，以及要采起哪些必要行动。质量计划包括质量控制、质量保证、持续改进措施等过程，以及在这些过程当中所要采起的沟通、受权、明确职责、编制质量管理文件、质量检查、审计、报告和审查等管理活动。

软件质量计划的详细内容和书写格式请看“10.3.4 计算机软件质量保证计划规范”。

3．质量保证

质量保证是保证质量计划得以系统地实施的所有活动，包括按期评价整体项目执行状况，以提供项目知足质量标准的信心。质量保证经过质量管理系统实现。创建和维护质量管理系统以保证有效的沟通和输出实施质量管理计划的结果。

软件质量保证是为保证软件系统充分知足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的软件。

软件质量保证的主要困难表如今如下方面：

（1）软件开发的管理人员每每更关心项目开发的成本与进度。由于成本和进度是显而易见的，而软件质量则难以度量。

（2）若是软件开发的管理人员对于交付的软件含有多少隐患并没必要负什么责任，他们一定没有过高的热情去控制开发的质量，更没必要说保证质量并不容易且代价昂贵。

（3）开发人员的习惯一旦造成便难以改变，他们的行为也难于控制。而高质量的软件产品，又主要取决于参与开发的人员。

（4）复杂的软件项目须要许多技术人员和管理人员参与，对问题的不一样认识和误解如不能及时消除必然影响软件质量。

（5）软件开发人员的频繁流动，特别是骨干开发人员的流失，也会使软件质量受到必定影响。

软件质量保证的主要手段：

（1）开发初期制定质量保证计划，并在开发中坚持实行。

（2）开发前选定或制定开发标准或开发规范，并遵守实施。

（3）从选择分析设计方法和工具，造成高质量的分析模型和设计模型。

（4）严格执行阶段评审，以便及时发现问题。

（5）各个开发阶段的测试。

（6）对软件的每次“变更”都要通过申请、评估、批准、实施、验证等步骤。

（7）软件质量特性的度量化。

（8）软件生存期的各阶段都要有完整的文档。

4．质量控制

质量控制活动具体监控软件项目的进程和结果，以肯定其是否符合相关的质量标准；分析产生质量问题的缘由，并制订相应措施来消除致使不符合质量标准的因素，确保项目质量得以持续不断地改进。质量控制活动包括经过由内部或外部机构进行的监测管理，发现与质量标准的差别，消除成果或过程当中不能知足质量要求的因素；还要审查质量标准，以肯定可能达到的质量目标及为此须要支付的质量成本，并评价其费用效率，必要时能够修订质量标准或项目目标。

5．质量改进

质量改进活动一般经过持续不断的纠正措施，并提出必要的变动申请，经过总体变动控制系统程序来实现。

 

软件能力成熟度模型：

CMM把软件开发过程的成熟度由低到高分为5级，即初始级、可重复级、已定义级、已管理级和优化级。随着CMM等级的提升，它逐步下降了软件开发风险，缩短了开发时间，下降了软件开发的人力物力成本，下降了灾难性的错误发生率，提升了软件质量。CMM评估等级的提高会大幅度提升软件开发能力，有助于客户特别是大公司对该软件企业创建信心，并向该软件企业下订单采购软件产品。

CMM的每一个等级由不一样的关键过程域（Key Practivice Area，KPA）组成，每一个关键过程域包括一系列的关键实践（Key Practivice，KP）。关键过程域是指互相关联的若干软件实践活动和有关基础设施的一个集合。关键实践则是指对关键过程域的实践起关键做用的方针、规程、措施、活动，以及相关基础设施的创建。CMM1.1中的5个等级共有关键过程域18个，18个关键过程域中包含KP共316项。CMM1.1的5个等级和18个关键过程域如表6-8所示。

表6-8 CMM1.1的5个等级和18个关键过程域

 

CMM做为评估软件过程成熟度的依据，为软件过程评估和软件能力成熟度评估创建了一个共同的参考框架。

 

软件过程改进非一日之功，急于求成必将致使失败。盲目进行过程改进，只会浪费时间和资金而不会取得好的效果。若是咱们把软件过程改进看作一个项目，像其余项目同样，它也要有一个好的规划，这个规划不但要知足公司的商业目标，还要包含过程改进战略和具体的实施步骤。

一般，软件过程改进可按如下步骤进行。

1．比较“目标状态”与“目前状态”，找出全部差距

（1）目标状态：若是一个机构决定采用CMM做为参考蓝本的话，就能够基于它的各个关键过程域（KPA），制定出符合本身机构及产品特色的目标状态。

（2）目前状态：要找出什么是目前的状态，就要进行对目前软件过程的评估。评估的方法不少，最简单的就是一组熟悉本机构的平常开发运做的人员在一块儿讨论，把它列出来。在这里，可借助CMM的评估问卷办法。实质上，评估问卷中的问题，就是由各关键过程域的各细则内容，加上“有没有作到”、“有没有创建”、“有没有执行”等语句而构成的，并无什么神秘之处。

2．肯定改进目标

找出全部差距以后，首先筛选出若干个改进点，并把每一个改进点都看作一个改进项目。对于每一个改进项目，可从该项目对公司商业目标的影响、风险程度、对公司达到更高CMM等级的贡献、投入产出比等方面进行分析评价。而后根据公司具体状况，肯定上述几方面因素所占的不一样权重，计算每一个改进项目的总分，并按照分值对各个改进项目进行排序。排序完成后，根据各个改进项目的优先级顺序和依赖关系肯定整体改进目标与阶段改进目标。

3．制定改进计划

软件过程改进计划一般要求以下。

（1）要有明确的、能够检验的目标。

（2）要定出检验成功与否的标准。

（3）要有具体的实施行动办法。

（4）要指定具体执行计划的人，以及每人的具体责任与任务；。

（5）要指明计划的主要领导或协调者，以负责解决一切在执行中出现的问题。

（6）要列出所采用的新技术与新工具，以及怎样得到它们。

（7）要定出对新技术和新工具进行对本机构适用性改造的目标。

（8）要有对新技术和新工具的使用进行培训的计划。

（9）要列出每一改进对过程的其余部分的关系、影响和协调的办法。

（10）要创建与项目相关联的时间表。

（11）要指出相关的人力、资金与时间的来源。

（12）要定出在整个执行过程当中，必须在何时提供什么数据。

（13）要有对执行状况进行监察考核的具体办法及计划。

（14）要准备极可能发生的、在执行过程当中对行动计划按状况进行调整的行动。

（15）要对行动计划执行中可能出现的意外状况有所准备，保证项目仍然可以顺利进行。

（16）必需要有高层领导、管理人员做为推进整个行动计划的动力。

4．执行改进计划

在执行过程当中，一旦发现须要对改进计划进行调整，以期达到最佳的效果，而实际状况也容许在中途进行调整的话，能够进行通过计划的、严加控制的调整。全部的改变必须预先取得全部有关人员的赞成。

5．总结本轮改进经验，开始下一轮改进

软件过程的不断改进是软件工程的基本原理之一，认真总结本轮改进的经验和教训能使咱们在下一轮改进中作得更加出色。

软件过程改进中，最重要的一点是要注重执行、作实事，千万不要制定出了改进计划以后就丢进抽屉中，束之高阁。另一个要注意的问题是，要有对改进计划执行中可能出现的意外状况有所准备，保证项目仍然可以顺利进行。

 

能力成熟度模型集成

与CMM相比，（能力成熟度模型集成，CMMI）涉及面更广，专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。据美国国防部资料显示，运用CMMI模型管理的项目，不只下降了项目的成本，并且提升了项目的质量与定期完成率。

CMMI能够看作把各类CMM集成到一个系列的模型中了，CMMI的基础源模型包括软件CMM、系统工程CMM，以及集成化产品和过程开发CMM等。CMMI也描述了5个不一样的成熟度级别。

每一种CMMI模型都有两种表示法，即阶段式和连续式。这是由于在CMMI的三个源模型中，CMM是“阶段式”模型，系统工程能力模型是“连续式”模型，而集成产品开发（IPD）CMM是一个混合模型，组合了阶段式和连续式二者的特色。两种表示法在之前的使用中各有优点，都有不少支持者，所以，CMMI产品开发群组在集成这三种模型时，为了不因为淘汰其中任何一种表示法而失去用户对CMMI的支持，并无选择单一的结构表示法，而是为每个CMMI都推出了两种不一样表示法的版本。

不一样表示法的模型具备不一样的结构。连续式表示法强调的是单个过程域的能力，从过程域的角度考查基线和度量结果的改善，其关键术语是“能力”；而阶段式表示法强调的是组织的成熟度，从过程域集合的角度考查整个组织的过程成熟度阶段，其关键术语是“成熟度”。

尽管两种表示法的模型在结构上有所不一样，但CMMI产品开发群组仍然尽最大努力确保了二者在逻辑上的一致性，二者的须要构件和指望部件基本上都是同样的。过程域、目标在两种表示法中都同样，特定实践和共性实践在两种表示法中也不存在根本区别。所以，模型的两种表示法并不存在本质上的不一样。组织在进行集成化过程改进时，能够从实用角度出发选择某一种偏心的表示法，而没必要从哲学角度考虑两种表示法之间的差别。

阶段式模型也把组织分为如下5个不一样的级别。

（1）初始级：表明了以不可预测结果为特征的过程成熟度，过程处于无序状态，成功主要取决于团队的技能。

（2）已管理级：表明了以可重复项目执行为特征的过程成熟度。组织使用基本纪律进行需求管理、项目计划、项目监督和控制、供应商协议管理、产品和过程质量保证、配置管理，以及度量和分析。对于级别2而言，主要的过程焦点在于项目级的活动和实践。

（3）严格定义级：表明了以组织内改进项目执行为特征的过程成熟度。强调级别3的关键过程域的先后一致的、项目级的纪律，以创建组织级的活动和实践。

（4）定量管理级：表明了以改进组织性能为特征的过程成熟度。4级项目的历史结果可用来交替使用，在业务表现的竞争尺度（成本、质量、时间）方面的结果是可预测的。

（5）优化级：表明了以可快速进行从新配置的组织性能和定量的、持续的过程改进为特征的过程成熟度。

CMMI的具体目标是：

（1）改进组织的过程，提升对产品开发和维护的管理能力。

（2）给出能支持未来集成其余科目CMM的公共框架。

（3）确保所开发的所有有关产品符合将要发布的关于软件过程改进的国际标准ISO/IEC15504对软件过程评估的要求。

使用在CMMI框架内开发的模型具备下列优势：

（1）过程改进能扩展到整个企业级。

（2）先前各模型之间的不一致和矛盾将获得解决。

（3）既有分级的模型表示，也有连续的模型表示，可任意选用。

（4）原先单科目过程改进的工做可与其余科目的过程改进工做结合起来。

（5）基于CMMI的评估将与组织原先评估得分相协调，从而保护当前的投资，并与ISO/IEC15504评估结果相一致。

（6）节省费用，特别是当要运用多科目改进时，以及进行相关的培训和评估时。

（7）鼓励组织内各科目之间进行沟通和交流。

 

1．软件配置与软件配置项

软件配置（Software Configuration）是指一个软件产品在软件生存周期各个阶段所产生的各类形式（机器可读或人工可读）和各类版本的文档、程序及其数据的集合。该集合中的每个元素称为该软件产品软件配置中的一个配置项（Configuration Item）。

随着软件开发过程的深刻，软件配置项的数量迅速增长，软件配置项的内容也随时可能发生变化。为了开发出高质量的软件产品，软件开发人员不只要确保每个软件配置项都正确，并且必须保证一个软件的全部配置项是彻底一致的。

2．基线

基线（Baseline）是指已经过正式复审的软件中间产品或软件文档，它能够做为进一步开发的基础，而且只有经过正式的变化控制过程才能改变它。简而言之，基线就是指已经过正式复审的软件配置项。

基线有助于咱们在不严重妨碍合理变化的前提下控制变化。在软件配置项变成基线以前，能够迅速而非正式地修改它。一旦创建了基线以后，虽然仍然能够实现变化，但必须应用特定的、正式的过程（称为规程）来评估、实现和验证每一个变化。

为防止不一样版本的软件工具所产生的结果不一样，许多软件工程组织将软件工具，如特定版本的编辑器、编译器和其余CASE工具，也做为软件配置的一部分“固定”下来，也就是“软件工具基线化”。

最经常使用的基线包括如下3种。

1）功能基线

功能基线是指在系统分析与软件定义阶段结束时，通过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指通过项目委托单位和项目承办单位双方签字赞成的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级赞成或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。

2）指派基线

指派基线是指在软件需求分析阶段结束时，通过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。

3）产品基线

产品基线是指在软件组装与系统测试阶段结束时，通过正式评审的批准的有关所开发的软件产品的所有配置项的规格说明。产品基线是最初批准的产品配置标识。

 

软件配置管理活动主要包括5项任务：对象标识、版本控制、变化控制、配置审计和配置报告。

1．对象标识

为了控制和管理软件配置项，必须单独为每一个配置项命名，而后用面向对象方法组织它们。能够标识出两类对象：基本对象和汇集对象。基本对象是软件开发人员在分析、设计、编码或测试过程当中建立出来的“文本单元”，例如，需求规格说明的一个段落、一个模块的源程序清单或一组测试用例。汇集对象是基本对象和其余汇集对象的集合。能够把汇集对象做为表明软件配置完整版本的一种机制。

每一个对象都有一个能惟一地标识该对象的“对象名”，以及有关的“描述”、“资源表”和“实现”。其中，对象名是无二义性地标识该对象的一个字符串。

在设计标识软件对象的方式时，必须认识到对象在整个生命周期中一直都在演化，所以，所设计的标识方式必须能无歧义地标识每一个对象的不一样版本。

2．版本控制

版本控制是指联合使用规程和工具，以管理在软件工程过程当中所建立的配置对象的不一样版本。借助于版本控制技术，用户可以经过选择适当的版原本指定软件系统的配置。实现这个目标的方法是，把属性和软件的每一个版本关联起来，而后经过描述一组所指望的属性来指定和构造所须要的配置。

3．变化控制

对于大型软件开发项目来讲，无控制的变化将迅速致使混乱。变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。典型的变化控制过程以下。

（1）变化评估——接到变化请求以后，应首先评估该变化在技术方面的得失、可能产生的反作用、对其余配置对象和系统功能的总体影响，估算其修改为本，并根据评估结果造成“变化评估报告”，提交变化控制审批者审阅。

（2）变化审批——变化控制审批者对变化的状态和优先级作最终决策，为每一个被批准的变化下达一个“工程变化命令”，描述将要实现的变化、必须遵照的约束，以及复审和审计的标准。

（3）变化执行——把要修改的对象从项目数据库中“提取”（check out）出来，进行修改并通过适当的评审或测试活动，而后将修改后的对象“提交”（chech in）进数据库，最后用适当的版本控制机制建立该软件的下一个版本。

“提取”和“提交”过程实现了变化控制的两个主要功能——访问控制和同步控制。访问控制决定谁有权访问和修改一个特定的配置对象，同步控制有助于保证由多人完成的并行修改不会相互覆盖。

4．配置审计

配置审计做为对正式技术复审的补充，主要审计配置对象的那些一般不在技术复审中考虑的特征，好比：修改时是否遵循了软件工程标准？是否在该配置中显著地标明了所作的修改？是否注明了修改日期和修改者？是否适当地更新了全部相关的软件配置项？是否遵循了标注变化、记录变化和报告变化的规程？

5．配置报告

配置状态变化对大型软件开发项目的成功有重大影响。当大量人员在一块儿工做时，可能一我的并不知道另外一我的在作什么。软件配置变化报告用于增强相关人员的通讯与协调，它主要包括如下内容：发生了什么事（What）；谁作的这件事（Who）；什么时间作的（When）；它将影响哪些其余事物（What Other）。

 

风险管理已成为软件工程项目管理的一项重要内容，其主要活动包括风险识别、风险分析（风险估算与评价）、风险应对（风险防范）和风险控制等。

 

1．风险识别

首先要识别风险来源，由此可预测风险事件的发生并识别风险症状。在立项、人员、计划、质量、成本、进度、合同、安全、技术、外包外购、沟通协调等各管理要素中都对应着可能的风险条件，能够用不一样的方法对风险进行分类。从宏观上来看，风险能够分为项目风险、技术风险和商业风险。项目风险包括潜在的预算、进度、我的、资源、用户和需求方面的问题，技术风险包括潜在的设计、实现、接口、检验和维护方面的问题，而商业风险则主要来源于市场。

风险识别的重要工做就是将潜在的风险找到，并在文档中体现出来。

 

2．风险估计（风险估算与评价）

风险分析就是估算与评价风险的过程，其目标是帮助项目管理人员决定在具体的风险面前采起什么态度：应对，接受，仍是忽略。

应从两方面来分析每一种风险：一是分析其发生的可能性；二是分析其可能带来的破坏性。要尽可能采用量化办法进行风险分析。经过量化分析，按照可能性和破坏力进行风险排序。对于那种可能性大、破坏力也大的风险就应该更加剧视。

 

3．风险应对（风险防范）

风险应对包括肯定风险策略和制定风险应对计划。

风险策略是指应对某一种具体风险的策略，如规避（转移）风险、减轻风险或接受风险等。可利用某种技术，如原型化、软件自动化、软件心理学、可靠性工程学，以及某些项目管理方法等设法规避或减轻风险。

风险应对计划主要包括风险管理计划和应急计划等。

 

4．风险控制

风险控制活动主要包括如下任务：随时追踪风险已经、正在和将要发生的变化；预测和判断风险的应对是否会引发更新的风险发生；对用于风险管理的资源配置进行调整；调整风险应对计划；采起临时紧急应变措施等。