软件质量提升的理论基础

这篇文章已经非常详细地介绍了软件质量提升的理论基础，特别是针对GJB5000标准进行了深入的探讨。以下是对文章进行正规化处理和适当内容添加的版本：

软件质量提升的理论基础

作者：Frank Xinghan Zhao

摘要

本文旨在探讨软件产品质量的重要性及其对用户体验和企业竞争力的影响。文章分析了软件质量管理的理论基础，特别是过程管理在提升软件质量中的作用，并详细介绍了GJB5000标准及其在软件质量管理中的应用。

关键词：软件工程，质量管理，GJB5000

绪论

在当今数字化时代，软件产品质量的重要性不言而喻。它不仅直接影响用户的体验，还关系到企业的竞争力。高质量的软件能够提高用户满意度，增强品牌信誉，并显著降低维护成本和潜在风险。相反，劣质的软件可能导致用户体验不佳，如卡顿或崩溃，进而导致用户流失。

软件质量是企业品牌形象的重要组成部分，也是企业争夺市场份额的关键因素。高质量的产品能够为企业赢得更多的市场机会，而劣质产品则可能引发用户投诉，损害企业声誉。此外，高质量的代码更易于维护，有助于降低成本和风险，而劣质产品则需要投入大量资源来修复漏洞。

因此，软件的设计和开发必须遵循高标准，从细节入手，全员参与，确保为用户交付优质的产品。只有这样，企业才能持续创新，保持市场活力。

针对过程的软件质量管理

在软件质量管理实践中，我们经常听到一线人员的抱怨，例如：“我们是搞技术的，你们把什么都做了规定，是在限制我们的创造力”，或者“你们搞这些，还不如多做一些测试，多在工程上投入一些，也比你们搞5000的有用”。作为一线软件设计和编码出身的我，特别能理解一线人员的科研压力。因此，我想探讨我们为什么要建立软件质量管理体系。

我们经常提到软件质量管理，并制定了许多软件质量措施。这些措施可以分为两个层面：直接针对软件质量的措施，如测试，以及针对过程的措施，如GJB 5000体系。那么，我们制定这么多过程要求，对软件质量有何作用？为什么针对过程管理能提升软件质量？

实际上，无论是9000体系、5000体系还是六西格玛等方法，都是通过制定一系列针对过程的要求，通过过程的稳定性来提升最终产品的稳定性。这些方法都基于一个公理：“过程越稳定，最终产品越稳定”。

因此，现代质量管理的核心是通过管理过程、控制过程、降低过程的波动，从而提升最终产品的稳定性。这也是现代质量管理学的一个理论基础。

软件质量管理模型

当然，这并不是说直接的质量控制，如质量检验和软件测试不重要。一个有效的质量管理应该兼顾过程管理和直接质量控制。

稳定与改进缺一不可

过程的稳定性带来了产出物的稳定性。然而，稳定性并不意味着品质一定高。要获得高品质的产品，还需要进行软件过程改进。

过程的相对稳定性和固化是过程改进的前提。如果过程不稳定，改进就无从谈起。而稳定的过程所带来的相对稳定的产出物质量，也使得我们能够对过程改进的结果进行评价，从而直观地判断过程改进是否符合预期。

对这个过程进行总结，我们可以得到：“过程稳定是改进的前提，过程改进是质量提升的途径”。过程稳定和过程改进是质量管理的两个方面，缺一不可。

在质量管理中，无论是硬件产品质量还是软件质量，都应该将持续改进视为管理的信条。我们在进行GJB5000审核交流时发现，一些企业虽然建立了相对完善的软件管理体系，但在几年内，体系文件基本没有变动和优化。这表明我们的软件质量体系建设只完成了基础性的一半，而最重要的另一半却被遗漏了。这丧失了我们实施5000体系的意义。

什么是GJB 5000

我们经常提到GJB 5000，许多软件单位也已经通过了GJB 5000的等级评价。那么，GJB 5000到底是什么？对于5000，我们可以从标准、体系和评价三个方面来理解。

首先，我们经常提到的5000标准，是中央军委装备发展部在2021年发布的GJB 5000B-2021《军用软件能力成熟度模型》。这是一个中国军用软件领域的能力成熟度模型标准，旨在提高军用软件产品的研制质量，确保软件能够在规定的时间和预算内开发出符合质量要求的产品。GJB 5000标准基于美国卡耐基梅隆大学软件工程研究所提出的CMM/CMMI模型，并结合了中国国内军用软件研制过程的特点。

GJB 5000标准分为五个成熟度等级：

初始级：基本的软件管理过程已经建立，但可能不够规范和系统。
规范级：已建立过程改进组织机构和过程规范，逐步积累组织资产。
全面级：全面建立并维护组织资产，按照组织标准过程，使用组织资产全面开展全生命周期项目管理、工程及支持活动。
量化级：建立了符合组织业务发展需要且较高的质量和过程绩效量化目标，采用量化分析管理技术，对关键过程实施量化管理及原因分析。
卓越级：通过量化评估业务目标并分析绩效数据，识别组织内的关键问题和共性问题，主动并预测性地优化和改进组织过程。

GJB 5000B标准规定了军用软件能力成熟度的模型和军用软件论证、研制、试验和维护活动中的相关实践，适用于军用软件论证、研制、试验和维护能力的评价和过程改进。实施GJB 5000B可以提高软件研制能力、单位工作效率、武器装备质量，并提升核心竞争力。

接下来，我们讨论5000体系。5000体系是一个企业或组织，根据自身软件特点和研发管理特性，结合GJB 5000标准的条款要求，针对内部软件生命周期全过程所制定的技术与管理要求。总的来说，5000标准是对全军的指导性要求，而5000体系是企业内部的要求，需要与企业自身的特性相符。

最后，我们讨论5000评价。5000评价是指由评价组织方组织专家组，代表装备发展部对军用软件研制单位按照GJB 5000标准进行的能力成熟度评估。评价流程主要包括：

申请单位需完成内部评估及整改，填报申请材料。
提交装备承制单位资格受理点，申请GJB 5000B换版评价单位通过受理点直接报送换版评价数据。
中央军委装备发展部授权的评价机构负责组织实施军用软件研制能力现场评价工作。
评价完成后，会有专家审查、装备发展部审批发证以及年度监督等后续流程。

GJB 5000标准分为五个成熟度等级，分别是初始级、规范级、全面级、量化级和卓越级。每个等级都有其特定的特征和要求，一般情况下默认申请单位已经具备了第一级，即初始级的要求，所以评价均要从第二级——“规范级”开始申请。正式评价通过后一年才可进行下一级的评价申请，中间不能有跳级。

在现场评价中，专家组采用SGAMPI（The Standard GJB 5000 Appraisal Method for Process Improvement）的A类评估方法，即在评价中收集证据以证明组织达到了要求。所收集的证据分为三类：

第一类证据：书面直接证据 这是必须提供的证据类型，它能够直接证明某个过程或活动已经发生。例如，如果评估的是软件开发过程，那么书面直接证据可能包括代码审查记录、测试报告、项目计划和会议记录等。这些文档能够直接展示过程的执行情况。
第二类证据：书面间接证据 这类证据虽然不能直接证明过程的执行，但可以间接支持过程已经发生。例如，如果一个项目计划已经制定，那么相关的资源分配记录、预算报告或人力资源记录可以作为间接证据，表明项目计划正在被执行。
第三类证据：访谈证据 通过访谈组织的成员来收集证据，这可以包括对项目经理、开发人员、测试人员等的访谈。访谈可以验证书面证据的真实性，并提供更多关于过程执行的细节。访谈证据需要评估团队成员具备良好的沟通和分析能力，以确保收集到的信息是准确和有效的。

在进行GJB 5000评估时，每一个实践域都需要提供类似这样的证据。第一类证据是必须有的，而第二类和第三类证据中至少需要提供一个。只有当这三类证据都具备时，才能充分证明某个实践域的过程得到了有效实施。

GJB 5000B是一个什么样的标准

在讨论GJB 5000B之前，我们需要思考哪些因素会影响软件的质量。首先，我们可以想到的是工程相关的活动，如需求分析、设计、测试、评审、项目论证、集成等。这些活动与产出物直接相关，其质量与产出物的质量息息相关。

因此，GJB 5000B的条文中，针对所有的工程活动环节，都做了明确的定义，内容包括：

立项论证（DEM）：在项目的早期阶段，进行系统的论证，确保项目的目标、需求和可行性得到充分的分析和确认。
需求开发与管理（RDM）：涉及需求的获取、开发、分析、确认以及管理，确保需求在整个项目生命周期中的完整性和一致性。
技术解决方案（TS）：包括设计实现准则的建立、设计方案的确定、开发购买或重用分析、产品或产品部件的设计、接口设计以及通用质量特性的设计。
产品集成与交付（PID）：涉及集成策略的建立、集成环境的维护、接口完整性和一致性的评审、待集成产品部件的确认、根据集成策略进行产品集成、评价已集成的产品或产品部件以及产品的部署和交付。
同行评审（PR）：通过同行评审来识别和纠正软件工作产品的缺陷，提高软件质量。
验证与确认（VV）：确保软件产品满足需求和预期的使用条件，包括制定验证与确认计划、进行验证与确认活动以及验证与确认记录的维护。
运行维护（MT）：涉及软件产品交付后的运行和维护活动，包括维护计划的制定、维护活动的执行以及维护记录的维护。

这些工程类实践域在GJB 5000B标准中被详细描述，并提供了实施这些实践域的具体目标和方法，以指导组织在软件开发过程中实施精细化的过程管理。

很明显，仅仅是工程类的实践还是不够的。软件如果想要做得好，除了工程实践外，作为项目的管理者肯定还是需要其他的管理实践才能让软件的质量具备一定的可控性，比如我们需要做计划、还需要以一定的频率监控项目的运行等。5000标准在这一方面也做了较为全面的规定。具体要求如下：

GJB 5000B标准中的项目管理类实践域主要包含以下几个方面：

项目策划（Project Planning, PP）：包括使用组织资产进行策划、项目估计、定义项目过程、制定项目计划、协调和管理利益相关方及活动间依赖关系等内容。目的是通过制定和维护合理适用的项目计划，增加项目目标实现的可能性。
项目监控（Project Monitoring and Control, PMC）：涉及监督项目策划参数的执行情况、跟踪项目资源计划的执行情况、协调与跟踪利益相关方参与项目及履行承诺的情况。当项目进展与计划显著偏离时，需要采取纠正措施。
外部供方管理（Supplier Agreement Management, ESM）：敏捷开发中没有直接对应的实践，需要按照GJB 5000B的要求进行。涉及管理与外部供方的协议，确保供方的工作符合项目要求。
风险和机遇管理（Risk and Opportunity Management, ROM）：建立并维护风险或机遇管理策略、分析和评价风险或机遇、制定并实施风险或机遇应对措施、监控并沟通风险或机遇的状态。

这些实践域通过确保项目的计划、执行、监控和风险管理等方面的有效性，帮助组织提高项目管理的成熟度，从而提升项目成功的可能性。

项目的研制方，在项目的运行之外肯定还是需要一定的措施，来帮助项目改进，比如拿到项目的统计数据，进行项目质量审核，查看项目是否按照体系和其他质量要求进行研制活动，技术状态是否可控，项目的文档，活动，代码等是否按照组织要求进行出入库及保存等。这些要求在5000体系中也有较为完备的规定。具体内容有：

GJB 5000B标准中的支持类实践主要包括以下几个方面：

配置管理（Configuration Management, CM）
- 涉及标识配置项、建立和维护配置管理系统、建立和维护基线、跟踪和控制变更、记录配置管理状态以及执行配置审核等活动。
- 目的是建立和维护软件工作的完整性和一致性，确保能够向客户提供正确的软件版本和工作产品。
质量保证（Quality Assurance, QA）
- 包括实施质量保证活动，确保项目遵循组织的过程和标准，以及确保工作产品满足质量标准和要求。
决策分析与解决（Decision Analysis and Resolution, DAR）
- 涉及分析备选方案、选择最佳方案、并记录决策过程和结果，以支持项目和组织的战略决策。
原因分析（Cause Analysis and Resolution, CAR）
- 包括识别问题、分析原因、采取纠正措施以及防止问题再次发生。
测量与绩效管理（Measurement and Performance Management, MPM）
- 涉及建立和维护测量系统、收集和分析数据、管理项目和过程绩效以及报告测量结果，以支持过程改进和决策制定。

这些支持类实践域通过提供必要的支持活动，帮助组织确保软件项目的质量和一致性，同时支持项目和组织的战略决策和绩效管理。

以上这些都是一个项目研制过程中必须做的，哪怕是不做GJB 5000体系，这些活动在软件项目研制过程中也是必不可少的。那么，这些是否已经足够？从质量管理上来说，这些都是项目级别的实践，但是作为组织，还是需要针对组织级的一些共性特征，做出一系列的管理规定才是一个完整的质量体系。

GJB 5000B标准中的组织类实践主要包括以下几个方面：

领导作用（Leadership, LD）：涉及组织领导层对过程改进的承诺和领导作用的发挥，确保组织过程能力满足业务目标。
组织过程改进（Organizational Process Improvement, OPI）：关注组织层面的过程改进，包括建立和维护组织过程资产，以及基于过程性能数据进行组织级别的改进。
组织资产开发（Organizational Asset Development, OAD）：目的是提升项目和组织的过程绩效，包括组织标准过程的制定、组织过程资产的开发和维护等。
组织培训（Organizational Training, OT）：涉及组织层面的培训活动，确保员工具备必要的技能和知识，以支持组织的过程和项目。
实施基础（Infrastructure, II）：包括为软件项目提供必要的基础设施支持，如硬件、软件、人员、信息资源等。

这些组织类实践域通过确保组织领导层的承诺、过程改进的实施、资产的开发和维护、员工培训以及基础设施的支持，帮助组织建立和维护一个有效的软件过程改进框架，从而提高软件项目的成功概率和组织的整体成熟度。

从上边的论述可以看出，GJB 5000B是一个非常完备的框架，建立了一个非常全面的模型来对软件质量的各个层面做出了要求。

（TODO：这里添加一个时间域的关系图）

GJB 5000标准的判定

我们研读GJB 5000，或者CMMI标准，我们都会发现一个问题：标准里都写了我们需要做什么，但没写我们需要怎么做，以及做到什么程度算是合格的。

例如：对于需求开发与管理，GJB 5000B标准2.6里写明了“建立并维护需求双向可追溯性（RDM 2.6）”，在标准正文里描述了需要建立软件产品从需求开发到最终产品的双向追踪，但并没有说用什么方法建立追踪，以及追踪的粒度精细化到什么程度才是合格的。其他的条文也都是这样的一种形式。

所以我们如果看标准，就会发现标准中，其实只描述了等级目标，与等级实践，也就是每个等级需要干什么，但都没有写具体的途径，步骤和程度。

那么，既然5000标准根本没说做到什么程度，那我们平时说的某项活动不符合5000标准，到底是怎么回事？

事实上，与法律法规不同，一个组织的活动是否符合5000的要求，这个红线并没有在5000标准里说明，而是由评价员掌握。至于评价员的判断依据，一般由如下的几个方面：

组织的被评活动是否满足组织自己制定的体系文件的要求。组织的软件工程活动一定要满足自己的质量体系的要求，这是5000评价用的最多的评价方式。
组织的被评活动是否满足合同或行业强制标准的要求，一些军用标准，如GJB438系列，TE标准，DO 178C等，假如在顶层文件里规定了研制过程需要按照这些标准执行，那么这些标准里的内容也可以作为判定依据。
评价员根据自己的工程经验，判定某项活动做的有缺陷，可能会带来一定程度的质量风险的，那么也是可以判定为问题。但是这一条需要慎用，因为任何质量控制活动都是需要成本的，被评方在某些方面做的有一定疏漏，或许是出于费效比衡量后的结果。

关于GJB5000的等级认识

在很多情况下，我们是把能力的高低和等级的高低等同起来。例如，在长跑领域，经过认定的国家二级长跑运动员，其长跑的运动表现在考核中是优于三级运动员的。我们在军品软件研发成熟度认定上，同样也有等级的规定。不论是美国的CMMI，还是我国的GJB5000B，都是将其设计成为了五个等级（具体见前文所述）。我们经常有个误区，将CMMI和5000等级和研发能力等同起来，认为三级的软件开发能力一定比二级强，其实这个看法并不是正确的。

不论是CMMI，还是我国的5000体系，如果看其名称，并不是一个研发能力评估/评价模型，其全称叫做“软件研制能力成熟度模型”。为什么叫成熟度，而不是研发能力，这俩者是有区别的。如果研究其条文，就会发现标准条文中，不同等级和能力并没有关系。相对于不同的等级，只是在生命周期的各个阶段的不同方面，要求的更全面，而并不是要求的能力更高。换句话说，如果把评价领域从软件开发换成做饭，不同的等级，相当于对做饭的不同方面要求的更细致，比如二级只对做饭的大致过程步骤（如如何热锅、如何装盘等）进行了规定，而三级就需要对更多的细节（如颠勺、放盐、尝菜等）进行细致的规定。三级规定的更细，但并不意味着三级的产出物更好。规定做的再细致，也并不意味着入门厨师烹饪的菜肴味道要比一个没规定的特级厨师要好。但是，如果把范围放宽到一个组织，规定的更细致，会极大的降低整个组织的所有产品的质量抖动，让所有的产品都有相对一致的产品质量。这就是高能力成熟度的意义。

当下，一些单位在追求四级甚至是五级的高等级成熟度，一些领导将这些作为政绩，写入到了单位的发展目标当中。我并不认为这种方式是值得推广的。因为四级或五级的高等级成熟度，需要大量的详实的数据才能发挥作用。我和一些高等级成熟度的专家讨论后一致认为，如果想真正做好四级和五级，特征相似的软件项目至少应该达到三十个以上，而且其测量数据也是要全面准确，只有这样其统计特征才相对明显且可靠。而这个要求对于很多单位来说是比较高的。单纯为了追求高能力成熟度，从而去造一批证据和数据，本身这种做法是不可取的。

关于软件质量提升的小结

软件质量提升，是一个很复杂的技术和管理结合的问题。从技术层面上讲，先进技术的引入是可以立竿见影的达到软件质量提升的效果。比如辅助编码工具，代码检查工具，单元测试工具，自动化测试工具等。另一方面，我们需要制定一套完备的体系，对工程、管理、支持、组织等方面进行规定，通过提升过程的稳定性来降低产品的质量抖动。而如何才能保证我们的体系是完整的，仅仅靠自己发掘其实是比较困难的，但是GJB5000B提供了一套完整的框架，可以帮助我们制定质量体系与评估实际工作。充分利用好GJB5000这一套方法，从技术和管理两方面，共同促进组织的质量进步，提升组织的研发效率，才能让组织的软件研发有一个稳定健康的发展路径。

GJB5000标准在软件质量管理中的作用与实施