第2章 软件品质管理要点

在阅读本章内容之前，首先思考以下问题：

1.软件品质管理的层次结构是什么？

2.品质管理体系包含哪些内容？

3.品质数据有哪些？

4.各阶段品质标准值是多少？

2.1 品质管理层次

首先，需要理解品质管理的层次是如何划分的，另外还要明白应该在哪个层次重点实施品质管理。如果实施重点品质管理的层次错了，品质管理就收不到预期的效果。

根据软件开发流程的特点，品质管理划分为横向层次；根据软件产品的结构特点，品质管理划分为纵向层次。品质管理层次的划分，可以使人们更加深入地了解品质管理在软件开发各个阶段软件产品从整体到细节的品质情况，其目的是便于品质保证与品质管理，进而提高开发者的品质管理意识。

2.1.1 软件开发的V模型

软件开发流程一般包括需求定义、需求分析、外部设计、内部设计、编码、单元测试、结合测试及系统测试8个阶段。无论是业务开发流程还是架构开发流程，都是“V”字模型，如图2-1所示。也就是说，代码对内部设计的反应如何，需通过单元测试来进行验证；相应的功能结合测试对应的是外部设计；业务结合测试对应的是功能定义与业务流程；系统测试对应的是需求整理的内容。

在软件开发过程中有很多任务（工作）对象，特别是大型软件开发。而对软件架构师来说主要关注的任务如图2-2所示。另外，软件架构师还必须了解项目启动阶段与需求阶段的各种重要信息，如系统鸟瞰图等。

2.1.2 横向层次

品质管理贯穿软件开发的整个过程，因此从开发流程角度，品质管理分为需求分析、外部设计、内部设计、编码、单元测试、结合测试与系统测试等层次，如图2-3所示。

2.1.3 纵向层次

由1.3.4小节可知，系统可划分为若干子系统，而子系统又是由各业务组成的，业务又由功能部分组成，而功能内部又划分为各种功能模块，如图2-4所示。根据软件自身构成的特点，对软件的品质管理的纵向划分也是如此。

图2-1 软件开发V模型

图2-2 软件架构师主要关注的任务

图2-3 品质管理的横向层次

图2-4 品质管理的纵向层次

2.1.4 横向层次与纵向层次的关系

品质管理的横向层次与纵向层次并不是孤立的。如图2-5所示，流程前期关注较高的是纵向层次，更注重于子系统、业务与功能；流程中期关注功能模块品质；流程后期关注更高的纵向层次品质。这样，在品质注入阶段先细分到模块层次，品质验证阶段再从模块开始，一层层集中起来，在这样相互交错的系列的工作中进行品质管理。

另外，在开发新系统时，对于客户来说系统还是一个空想的系统，通常客户一开始对自己的需求并不十分明确，很多潜在的需求需要通过某些契机来挖掘。因此，在需求与外部设计阶段确定之后经常会有功能的变更、增加与删除，这也是很正常的现象。对于开发方来说，进入开发期后，也要时刻准备满足客户的新需求，但是受到交货期和费用的限制可能无法全部满足，处理技巧有很多，具体内容可参照“经典案例十二”。

最终客户期待的是理想的系统，以魅力品质为要求的软件开发，最终必能超出客户的预期。

图2-5 品质管理阶层的细化

2.2 品质数据

2.2.1 品质数据概念

品质数据，是在品质注入阶段（外部设计/内部设计/编码）及品质验证阶段（单元测试/结合测试/系统测试）进行品质评价的基础数据，主要对象见表2-1。

表2-1 品质数据种类

品质数据是实施品质管理的最佳证明材料，俗话说“巧妇难为无米之炊”，如果没有这些基础数据就无法进行品质分析。一旦对这些品质数据的把握与收集懈怠，那么项目往往就会成为“问题项目”，而且这样的问题项目在实际开发中举不胜举，因此要切实地管理与用好这些基础数据。

2.2.2 品质数据收集时机

人们知道品质数据很重要，然而数据却是时时变化的，如果不把握好统计的时机，所得出的数据的有效性与价值就会大打折扣，因此把握时机非常关键。那么，什么时候进行数据统计才可以得到最佳效果呢？图2-6展示了开发各个阶段品质数据把握的关键时机。

图2-6 品质数据把握时机

图2-6左侧是品质注入阶段的规模计算。这部分需要掌握设计书规模大小以及设计书评审数据。设计完成时，要根据本阶段的设计情况预估系统规模，再用此数据来推测项目预算与工期的风险。

图2-6右侧是品质验证阶段的规模计算。这个测定需要在本阶段开始前进行，在本阶段结束后再次统计规模。之后对前后规模进行分析：如果有较大变化，那么就需要判断是设计不良还是编码不良。根据分析的实际情况采取必要行动。另外，还需要判断由于规模的增减（整体规模与各功能模块规模）是否需要增加测试。

在软件开发过程中，很多情况下是对旧系统的改造，改造过程中旧系统的部分功能可能会被重新利用，如图2-7所示。计算规模时，也要区分新开发代码规模与重用规模。

图2-7 规模构成

另外要注意以下几个品质数据的区别。

（1）估算规模

为实现设计书的内容事先对所需要的软件规模进行推测的软件代码规模。

（2）测试规模

测试对象代码的实际规模，具体内容可参照5.1.3小节。

（3）代码规模

代码规模，不是估算值，而是实际规模的计算值。

注意：实际计算代码规模时，按照通用的计算方式只计算实际代码行数，不计算空行与注释。在Java领域，一般指的是HTML、JSP、JS、CSS、XML、Java、SQL及Shell等文件格式的代码。代码行数统计工具很多，给大家推荐一款Eclipse免费插件——StepCounter。如图2-8所示，在统计数据时，代码行数指的是Actual这列。

图2-8 代码行数统计

经典案例四：把握品质数据变化的重要性

某承包商承包了一款软件的从提案到系统测试阶段的软件项目开发，可是在外部设计阶段发现规模有大的变更，那么应该如何处置呢？

案例解析：

作为项目PM，最大的责任是什么呢？如果学过PMP，就会知道——是用有限的资源成功完成项目，而资源的最终表现形式就是成本。在项目开发中保证项目成功的方法与手段很多，其中，最小的误差估算是最重要的一个。如何保证估算的误差最小呢？这就需要PM把握各个阶段规模变化的数据，特别是项目从最初提案书中的规模估算到详细设计阶段中各个阶段的规模估算。随着设计越来越详细，对系统的把握与认识也越来越深刻，那么在需求分析、外部设计及内部设计完成后，估算的规模有没有大的差异？能否在预算内完成项目呢？这个责任对PM来说是至关重要的。

任何项目都有风险。如果成本在设计的某个阶段评审后有很大的提升，那么这个时候就需要在当前阶段进行规模缩减（只有在设计阶段和客户商谈才能占据主动性），否则就很有可能超过预算。如果此时没有和客户商讨预算规模（增加工程附议或者减少功能），那么到软件编码阶段才认识到就已经晚了，如果此时减少功能，系统就有可能运转不良。

如果是少许地增加功能，那么可以在提高生产力上多下功夫，力争在预算内完成项目。因此，对各阶段的规模进行预估并分析是否有偏离，是项目经理必做的事情之一。

2.2.3 品质数据收集方法

因为品质评价的单位是模块，因此收集品质数据时要以功能模块为单位进行收集，所以在使用品质管理工具时，最小阶层要设置到模块级别，如图2-9所示。

图2-9 品质数据收集方法

2.3 各阶段品质标准值

2.3.1 品质管理解密之四：底线原则

所谓底线原则，就是构建软件品质管理的底线（红线），为各阶段制定品质标准值，不逾越底线。

各工程阶段开始前，为确保该阶段的品质水平，需要设定本阶段的品质标准值。

开发过程中的主要品质要素有以下4个（衡量品质的尺度）：

①评审密度（分/页）；

②错误密度（件/100页）；

③测试密度（件/KS）；

④故障密度（件/KS）。

品质标准指的是各阶段品质要素的目标值，如果超过目标值就需要采取措施，如图2-10所示。

图2-10 品质目标水准

品质水准要根据实际情况进行设置。在有委托项目时，要与对方PM沟通，确立相应的品质水准。

从实践中总结的底线原则实施时的重要技巧有以下3点。

（1）满足要求

即满足与客户约定的产品品质要求。

（2）最少资源

为满足品质要求及过程管控的需要，企业决策层应配备项目品质管理的最少资源。这些资源包括设备、人员、必要的培训及相应的授权等。

（3）禁止作假

这种作假包括检验数据弄虚作假等。弄虚作假的行为，往往是品质事故的一大根源。作假行为有企业行为和员工行为：企业行为是企业授意员工作假以在客户面前显示更漂亮的数据；员工行为则是员工自主的作假行为，例如员工为应付检查，将未及时填写的报表用想当然的数据填上。

软件产品开发若能守住底线原则，就一定不会出现混乱不堪的局面。

2.3.2 品质注入阶段的品质标准值

评审密度标准值是设计阶段式样品质评价的要素之一，计算方法是本轮评审时所评审式样书的平均评审时间（分钟/页），如表2-2所示。

注意：评审密度没有上限，因此如果业务比较复杂，那么也许评审时间比设计时间还要多。

表2-2 评审密度标准值

错误密度标准值是设计阶段式样品质评价的要素之一，计算方法是100页的式样书中的错误件数（件/100页），如表2-3所示。

表2-3 错误密度标准值

2.3.3 品质验证阶段的品质标准值

测试密度标准值是验证阶段代码品质评价的要素之一，计算方法是1000行代码中的测试件数（件/KS），如表2-4所示。

表2-4 测试密度标准值

故障密度标准值是验证阶段代码品质评价的要素之一，计算方法是1000行代码中的测试件数（件/KS），如表2-5所示。

表2-5 故障密度标准值

实际工程中，如果故障密度与计划值接近，那么故障就是收缩中，品质就会比较稳定。如果测试用例全部测试完毕，故障也解析应对完毕，那么就可以说故障收缩了么？要知道，测试用例不可能完全覆盖所有的测试内容，而且测试结果也不一定准确无误；测试遗漏的现象也时有发生，因此系统测试后遗留潜在故障的可能性就非常高。此时，故障收缩的真正含义就是：故障有事前预测，如果实际值与其相近，那么品质状况就是收缩状态中，不会有太大的品质问题；当然在允许的范围内还是有些潜在的故障，这些潜在故障就是运行时期品质保障范围内的工作。因此，预测精度越高，故障收缩的判断精度也就越高，测试结果的品质信任度也就越高。

扩展应用：有些大项目，开发周期比较长，为了保证品质，测试阶段会做很多划分。例如，IT被划分为IT1（功能内处理的结合测试）、IT2（功能间的结合测试）、IT3（业务间功能的结合测试）3个阶段来进行测试。那么再次细化后的各阶段的故障检出标准应该如何计算呢？很多程序员以为都按照标准值（例如：IT1=IT2=IT3=4.2）来计算。实际上如果这样计算，最终品质应该如何判定呢？按照哪次的来计算？因此这样是行不通的。正确算法应该按照前多后少的原则，而不是平均值。一般来说，分两次的情况下是2∶1的关系（即IT1=2.8，IT2=1.4），分3次的情况下是3∶2∶1（即IT1=2.1，IT2=1.4，IT3=0.7）的关系。

2.3.4 预测故障件数算法

预测故障件数算法以标准件数为基准，根据项目难易度等指标进行加权计算。加权项目主要有以下4个方面。

1.α：系统难易度

系统难易度指的是以编码的复杂性、独立性、沟通的畅通性等方面来进行权衡，系数设定在0.7～1.2之间。如果难度不是非常高，一般设定为1（例如：办公自动化系统这种比较简单的可设定为0.7；邮件产品可设定为1；而对于特殊系统如与硬件有电文交互的，以及银行系统等难度比较高的，可设定为1.2）。

2.β：语言系数

语言系数指的是用开发技术语言来进行加权，系数设定在1.0～1.2之间。一般来说，微软系与Java系都可以设定为1，因为已熟知技术人员比较多，遇到技术难题也容易到网上查询解决。如果是COBOL等大型机或者其他比较生僻的语言开发的话，可以设定为1.1或1.2。

3.γ：改造系数

改造系数指的是改造率，改造率按照正态分布，系数设定在0.86～1.29之间。新建的情况下，设定为0.86；改造率为50%的情况下设定为1.29，如表2-6所示。

表2-6 改造率与改造系数

※改造率=改造规模÷整体规模×100%

4.δ：程序员系数

程序员系数指的是参加项目程序员的技术能力，系数设定在0.5～2.0之间。整个项目的程序员系数是整体项目组成员的平均水平。

设计阶段使用的SE技术能力水平由高到低顺序（A～D），如表2-7所示。

表2-7 工程师（SE）能力划分级别

开发阶段使用的程序员（PG）技术能力水平由高到低顺序（A～E），如表2-8所示。

表2-8 PG能力划分级别

预测故障件数的基础值就是系统的代码规模C（Code，单位：KS）与标准故障数S（Standard，单位：件/KS）的乘积。而预测故障的算法：

预测故障件数=C×S×α×β×γ×δ

注意：这里的预测故障件数算法，不仅适用于整个项目，也适用于个别业务，亦适用于针对每个程序员所担任测试内容的故障值预测。

2.4 品质管理项目

2.4.1 定量品质分析管理项目

定量分析的对象就是需要进行品质管理的项目。因为在各个阶段分析的对象不同，所以需要管理的资材就不一样，表2-9对其进行了总结。

表2-9 定量品质分析管理项目

注意：表2-8中前10项与表2-9中前6项内容，要根据项目大小（中大项目：8个月以上，峰值人数15人以上；小规模：2～8个月，峰值人数5～14；微小项目：2个月未满，峰值人数不足5）进行取舍。而表2-8与表2-9中剩下的项目与项目成本有很大关系，PM一定要注意及时进行确认与把握。

2.4.2 定性品质分析管理项目

同样，定性品质分析管理项目如表2-10所示。

表2-10 定性品质分析管理项目

2.5 品质分析报告写作技巧

进行品质分析时，要经过定量品质分析与定性品质分析，最后形成品质分析报告。品质分析报告范围请参照附录B5。

2.6 品质判定

品质判定是项目品质管理工作中的重要环节。该阶段的品质是否有保障，是能否进入下一阶段工作的判定标准。

品质判断的最终结果就是品质判定等级，简称“品质等级”，是对本次任务的成果物进行品质判断结果的划分，如表2-11所示。品质判定合格并经过PM审批后可以开展下一阶段的工作。如果判断品质有问题，那么就要通知PM采取补救措施。如果各阶段判定都可以达到优秀，那么最终得到客户魅力品质判定的机会就会很大。

表2-11 品质等级

注意：判定时，要读什么数据，从数据里读取出什么，能做出什么样的判断，这是判定时的重点。要进行正确的判定，需要注意以下几点。

①关注哪些品质数据。

②如何分析与评价各种数据。

③如何进行多个评价项目相结合的综合诊断。

在定性分析方面必须尊重数据与事实，除了需要具备品质管理员要求的经验与毅力以外，也需要灵感与智慧。

（1）经验与毅力

确认现象，追究原因，考虑对策，品质管理主要关注的是一个管理者决断力的强弱。

（2）灵感与智慧

将不能直接用逻辑进行处理的部分进行关联。

2.7 采取行动

2.7.1 项目成员培训与指导

很多参与项目的成员都有这种体验：进入项目后既不清楚该项目的品质管理要求，又不知道这些文件在哪里能找到。于是，就凭着自己的经验与习惯进行作业。出现这种问题是管理的失职，也是自己的品质意识不足。所以，品质管理者要做好对所有成员的教育工作，特别是品质管理流程与要求，要在项目组内通知。

项目成员教育注意事项有以下3点。

（1）制作培训规范

新人培训规范要系统、完整，主要内容一般如下：

①必看资材一览（例如：项目简介资料，项目规定、规约、安全事项等）；

②参照资材一览（例如：旧项目设计资材、类似项目资料等）。

（2）进入项目组时进行培训

为统一思想，新人进入项目组时要给出一定时间（一般一周以内）来进行教育。教育形式一般是由项目经理先进行项目大概内容与资材的介绍，之后就是成员的自学与探讨。

（3）即时指导

项目进行期间，根据发现问题的影响范围进行全员的即时指导。

2.7.2 品质管理解密之五：体系化原则

体系化原则是指品质管理要形成体系，不再是单点作战，亦不再是只依赖品质验证来进行品质管理，如图2-11所示。图中基本包含了软件品质管理体系相关的各种元素及品质管理流程，相关内容十分丰富，要下功夫进行掌握。

在从分析需求到最后把产品交付给客户的整个开发流程中，精细化的品质管理模式横向分为品质注入阶段与品质验证阶段。在每一个阶段内纵向采用品质管理思维方式进行管理，这样，横纵的品质管理方法与技巧就组成了完美的品质管理体系。

图2-11 品质管理体系

在整个体系的实践活动中，采取行动是品质管理工作中的最大难关。如前所述，在断定品质有问题时需要明确其理由，并向项目组长或PM提出改善要求，且跟踪其实施结果。

在采取行动时要注意以下要点。

①不要错过时机，因为时过境迁。

②不能只发出指示，要监督相关人员立刻行动起来。

③改善方案的进度管理要彻底。

④不要忘记改善方案的品质管理与分析，不能放任自流。

其中，第一点非常重要。如果错过时机，就无法达到预期效果，必然会带来损失。而且要注意防微杜渐，及时跟踪项目品质。

从实践中总结的体系化原则实施时的重要技巧有以下5点。

①进行品质规划，建立切实可行的品质目标、品质组织、品质发展路线图等。

②对人员进行系统性的培训。

③客户服务与设计优化等工作要有机统一。

④建立品质大数据系统，这些大数据包括生产不良数据、客户抱怨数据、改善的追踪数据、文件记录数据、潜在失效更新等数据。

⑤建立企业品质文化——学习文化与改善文化。

及时周知

品质管理流程与要求要在项目组内进行周知，开发过程中发现的共性问题亦要彻底进行周知管理。

小结

本章内容是品质管理实践的准备阶段工作。品质管理实践时，根据实际情况决定所需事项，从而进行有效品质注入与品质验证；同时，需要收集各阶段品质数据以便进行定量与定性分析；之后根据分析结果采取行动——这就是品质管理工作最基本的流程。

练习题

1.软件开发流程包含哪几个阶段？

2.应该如何收集品质数据？

3.品质管理解密五的原则是什么？

4.IT阶段被划分成IT1、IT2和IT3，那么每次的目标指定值应该如何设定？

5.如表2-12所示，如果客户案件预计规模是400K，要求品质验证阶段合计故障标准值是8，那么品质验证的各阶段故障标准值应该是多少？总体预测故障件数是多少？

表2-12 计算各阶段故障标准值及总体预测故障件数

6.品质的4个等级是什么？

7.写一份结合测试的品质分析报告。