标签：特性 ase other 概念 cte 维护 局限性 评估 执行
软件质量管理
软件是逻辑产品，其质量属性有不同的特点。软件质量保证（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．风险控制
风险控制活动主要包括以下任务：随时追踪风险已经、正在和将要发生的变化；预测和判断风险的应对是否会引起更新的风险发生；对用于风险管理的资源配置进行调整；调整风险应对计划；采取临时紧急应变措施等。
软件评测师笔记_软件质量管理基础20161022
标签：特性 ase other 概念 cte 维护 局限性 评估 执行
原文地址：http://www.cnblogs.com/Btest/p/6103349.html
