软件质量管理.docx

第9章 软件质量管理 2
9.1 软件的质量属性和质量要素 2
9.2 商业目标决定质量目标 3
9.3 质量保证能够保证质量吗 4
9.4 质量人员的状况 6
9.4.1 郁闷的质量人员 6
9.4.2 路在何方 7
9.4.3 赞美诗 8
9.5 全面软件质量管理 9
9.5.1 模型 9
9.5.2 质量人员的职责 10
9.5.3 制定质量计划 11
9.5.4 技术评审 13
9.5.5 软件测试 16
9.5.6 过程检查 16
9.5.7 缺陷跟踪工具 17
9.6 小结 19
第9章 软件质量管理

软件质量管理是充满争论的话题。被人们奉为软件质量管理圣经的CMM和ISO9001似乎并不奏效，现实和理想之间的差距太大。
本章树立一个重要的理念：商业目标决定质量目标。提高软件质量的最终目的是为了赢利，而不是创造完美无缺的产品。因此对于普通商业软件而言，并不是“质量越高越好”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。
经典软件工程教科书以及CMM和ISO9001总是抛开商业目标谈质量管理，本末倒置，纸上谈兵，误导了大量读者，所以质量管理才变得那么艰辛。本章给出了一套实用主义的“全面软件质量管理”方法。
质量人员在全面软件质量管理中发挥重要作用，本章探讨了质量人员的工作状况，给他们一些声援，并提出了改善工作状况的建议。

9.1 软件的质量属性和质量要素
在讲述软件质量管理方法之前，我们首先要搞清楚什么是软件质量。
词典对质量的定义是：① 典型的或本质的特征；② 事物固有的或区别于其他事物的特征或本质；③ 优良或出色的程度。
CMM对质量的定义是：① 一个系统、组件或过程符合特定需求的程度；② 一个系统、组件或过程符合客户或用户的要求或期望的程度。
上述定义很抽象，人们看了准会一脸迷惘。就让我们用“人的健康”来类比解释软件质量吧。
古时候人们以为长得结实、饭量大就是健康，这显然是不科学的。现代人总是通过考察多方面的生理因素来判断是否健康，如测量身高、体重、心跳、血压、血液、体温等。如果上述因素都合格，那么表明这人是健康的。如果某个因素不合格，则表明此人在某个方面不健康，医生会对症下药。
通过类比，我们这样理解软件质量：
软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们通过改善软件的各种质量属性，从而提高软件的整体质量（否则无从下手）。

软件的质量属性很多，如正确性、精确性，健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等。表9-1是常见质量属性的描述，先让读者对软件质量属性有个初步的了解。

质量属性
描述
正确性
正确性是指软件按照需求正确执行任务的能力。“正确性”的语义涵盖了“精确性”。正确性无疑是第一重要的软件质量属性。
健壮性
健壮性是指在异常情况下，软件能够正常运行的能力。正确性与健壮性的区别是：前者描述软件在需求范围之内的行为，而后者描述软件在需求范围之外的行为。健壮性有两层含义：一是容错能力，二是恢复能力。
可靠性
可靠性是一个与时间相关的属性，指的是在一定环境下，在一定的时间段内，程序不出现故障的概率，因此是一个统计量，通常用平均无故障时间来衡量。软件可靠性问题通常是由于设计中没有料到的异常和测试中没有暴露的代码缺陷引起的。
性能
性能通常是指软件的“时间—空间”效率，而不仅是指软件的运行速度。人们总希望软件的运行速度高些，并且占用资源少些。
易用性
易用性是指用户使用软件的容易程度。软件的易用性要让用户来评价。
清晰性
清晰意味着工作成果易读、易理解，开发人员只有在自己思路清晰的时候才可能写出让别人易读、易理解的程序和文档。
安全性
安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、风险等因素）高于得到的好处，那么这样的系统就可以认为是安全的。
可扩展性
可扩展性反映了软件适应“变化”的能力。在软件开发过程中，“变化”是司空见惯的事情，如需求、设计的变化，算法的改进、程序的变化等。可扩展性是系统设计阶段重点考虑的质量属性。
兼容性
兼容性是指两个或两个以上的软件相互交换信息的能力。兼容性的商业规则是：弱者设法与强者兼容，否则无容身之地；强者应当避免被兼容，否则市场将被瓜分。
可移植性
软件的可移植性指的是软件不经修改或稍加修改就可以运行于不同软硬件环境（CPU、OS和编译器）的能力，主要体现为代码的可移植性。
表9-1 常见质量属性的描述

什么是软件质量要素？它是指：
（1）从技术角度讲，对软件整体质量影响最大的那些质量属性才是质量要素；
（2）从商业角度讲，客户最关心的、能成为卖点的质量属性才是质量要素。
对于一个特定的软件而言，我们首先判断什么是质量要素，才能给出提高质量的具体措施，而不是一股脑地想把所有的质量属性都做好，否则不仅做不好，还可能得不偿失。
如果某些质量属性并不能产生显著的经济效益，我们可以忽略它们，把精力用在对经济效益贡献最大的质量要素上。简而言之，只有质量要素才值得开发人员下功夫去改善。
9.2 商业目标决定质量目标
大凡软件工程教科书为了强调质量的重要性，总是要举一些历史上发生过的重大软件质量事故，例如航天飞机爆炸、核电站失事、爱国者导弹发生故障等等。这些事故的确不是危言耸听，给人们敲响了质量的警钟。
学术界总是喜欢宣扬质量至上的理念，而忽视企业的商业利益，将质量目标凌驾于商业目标之上。我不能评判这种现象是好还是坏，但是的确误导了大量读者。许多软件人员都有“质量越高越好”的观念，这是被教科书灌输的，而不是他自己领悟出来的。
质量的最高境界是什么？是尽善尽美，即“零缺陷”。
我曾在著作《高质量程序设计指南——C++/C语言》中大肆宣扬了高质量程序设计的理念，力求使C++程序达到“零缺陷”的质量目标。尽管此书得到了许多程序员的赞同，但是我经过反思之后改变了质量观念，我要着重指出的是：
重视软件质量是应该的，但是“质量越高越好”并不是普适的真理。只有极少数软件应该追求“零缺陷”，对绝大多数软件而言，商业目标决定了质量目标，而不该把质量目标凌驾于商业目标之上。

航空航天等系统对质量要求极高，任何缺陷都有可能导致机毁人亡，所以人们不惜一切代价去消除缺陷。在发射航天器之前，只要发现任何异常，就会立即取消发射指令，直到异常被消除为止。前苏联做得最过分，许多重大武器系统的负责人都签了生死状，系统研制成功则获得英雄勋章，失败则被枪毙。在这种压力下没有人敢对质量有一丝松懈。
上述严格系统毕竟是少数，绝大多数普通软件的缺陷并不会造成机毁人亡这样的重大损失，否则没有人敢从事软件开发了。在日常工作中，我们接触过的软件几乎都是有缺陷的，即便是软件业老大Microsoft，它的软件产品也经常出错甚至导致死机，人们骂几句后还会照样使用有缺陷的软件。
企业的根本目标是为了获取尽可能多的利润，而不是生产完美无缺的产品。如果企业销售出去的软件的质量比较差，轻则挨骂，重则被退货甚至被索赔，因此为了提高用户对产品的满意度，企业必须提高产品的质量。但是企业不可能为了追求完美的质量而不惜一切代价，当企业为提高质量所付出的代价超过销售收益时，这个产品已经没有商业价值了，还不如不开发。
企业必须权衡质量、效率和成本，产品质量太低了或者太高了，都不利于企业获取利润。企业理想的质量目标不是“零缺陷”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。
9.3 质量保证能够保证质量吗
质量保证（Quality Assurance, QA）是CMM和ISO9001最为推崇的改善软件质量的方法。基于我亲身实践和调查研究，我敢冒天下之大不讳说一句：质量保证并不能保证质量，它是个美丽的谎言。
CMM对软件质量保证是这样描述的：
软件质量保证的目的是为管理者提供有关软件过程和产品的适当的可视性。它包括评审和审核软件产品及其活动，以验证其是否遵守既定的规程和标准，并向有关负责人汇报评审和审核的结果。
简而言之，质量保证活动就是检查软件项目的“工作过程和工作成果”是否符合既定的规范。如此简单的活动为什么被冠以“质量保证”这等份量的术语呢？
没有历史典故，经我考究，猜想是源于一个天真的假设：
过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”，而“差的过程”将产生“差的产品”。假设企业已经制定了软件过程规范，如果质量保证人员发现某些项目的“工作过程以及工作成果”不符合既定的规范，那么马上可以断定产品存在缺陷。反之，如果质量保证人员没有发现不符合既定规范的东西，那么也可以断定产品是合格的。
基于上述假设，质量保证人员即使不是技术专家，他也能够客观地检查和监控产品的质量。这是质量保证方法吸引人的一面。
但是符合既定规范的东西并不意味着质量一定合格，仅靠规范无法识别出产品中可能存在的大量缺陷。例如，即使程序员们都按照统一的编程规范来编写程序，但是编程新手的代码可能错误百出，而高手的代码则无可挑剔，可是质量保证这种方法根本无法识别新手和高手的差距。质量保证的技术含量太低了，只能检查出肤浅的缺陷，不能对付有技术难度的缺陷。所以单独的“质量保证”其实并不能“保证质量”。
有个软件公司过了CMM3级，其质量保证人员给我发了一个email：
我很迷茫，很想找一个人聊聊，希望你能给我点主意，化解我心中的谜团。
昨天我们公司拿到了CMM3的证书，但是我一点都高兴不起来。公司宣称，我们的软件质量大大提高了，但是我却没有信心。我们的过程执行得很好，但是我觉得并没有在很大程度上改善产品的质量。
今天还有一个项目经理跟我诉苦：前一阶段大家都忙于执行过程，但是他的产品质量令人很不满意，尤其是测试做的很不到位。我是这个项目的SQA，所以我很理解他，但是我帮不上他的忙。因为他们的过程执行得很好，这个项目可是通过CMM3级正式评估了的。
当然，执行CMM有不少好处，比如文档全面完整了，项目管理的可视性提高了。但是对于我们公司而言，它并没有在根本上提高我们公司的软件能力。
比如概要设计，开发人员根本就不知道用来干吗的，怎么能指望他们写出高质量的概要设计说明书出来。而在做技术评审的时候，他们很少能找出逻辑性的错误，只能发现一些诸如错别字之类的小错误。我们几乎每一个配置项都要经过评审，但是大部分评审都只能发现一些无关痛痒的问题。
公司已经通过CMM3级了，我认为过程执行得很好了，可是软件质量仍然比较差。这是怎么回事啊，你觉得原因在哪里？

这个email很有代表性，它反映了一个共性问题：公司按照CMM3级的要求执行，而且质量人员也认为执行过程符合既定的规范，但是软件产品的质量仍然低下。
所以我说“质量保证并不能保证质量”，这句话一点都不过分。质量保证对于保证质量而言只是必要的手段，而不是充分的手段。质量保证这个术语名不副实，含义模糊，我强烈建议将“质量保证”改名为“过程检查”，免得误导国内企业。
那么怎么才能保证软件的质量呢？请阅读本章第5节“全面软件质量管理”。
9.4 质量人员的状况
9.4.1 郁闷的质量人员
由于工作关系，我和不少软件机构的质量人员打过交道。我觉得有必要反映一下质量人员的状况，给他们一些声援。
接上个email，那位质量人员继续向我诉说：
我现在觉得很郁闷，CMM评估前还有目标，评估完了冷静下来却觉得效果很差，很没劲。项目经理向我诉苦，他们过程执行的很好，但是对产品质量很不满意，我却无能为力，我这个QA还有什么用处啊！所以我现在干活没有动力，因为不能产生效益，做再多的工作也觉得是白干。而且我现在手头有5个项目要跟踪，还不包括一些整理培训记录的杂活，我觉得自己连工人也不如。我有一些很好的想法却无处发挥，所以我很迷茫，很矛盾地考虑去留问题。
类似的email我大概收到十来个。
在汉语字典里找不到“郁闷”这个词，它是现代人发明的。郁闷的滋味各色各样，只有正在郁闷的人感受最真切。我发现在软件职业里，质量人员是最郁闷的一族。郁闷的共同特征有：
（1）在执行质量保证活动时，经常受别人的气，真是吃力不讨好。
（2）如果项目取得成功，主要功劳都被项目主管霸占了，领导们至多会给质量人员一些口头上的感谢。领导们嘴上重视产品的质量，但是内心并不重视质量人员。
（3）质量人员没有实质性的权力，没有成就感，但是却对质量负有最多的责任。
（4）待遇一般，看不到升迁的机会，没有盼头，要么成为打杂的，要么另寻出路。

在企业里，职位是有高低之分的，但是人人都是平等的。郁闷的滋味是很不好受的，为啥老是让质量人员郁闷呢，这显然很不公平。我曾经做过伤害质量人员的事情，现在良心发现，在这里道个歉，并声援他们。
两年前，我在一个软件事业部负责推广软件工程和CMM。公司领导比较重视，给我6个全职人员，有充足的资金，声势浩大，那时我比较自负，很少采用协商的方式解决纠纷。公司有专门的质量部门，定期到各事业部检查质量。由于我们事业部采用的是CMM，而质量部门采用的是ISO9000标准，我不懂他的，他不懂我的，所以产生了纠纷。事业部的各级领导都有销售压力，用他们的话说是：没有时间陪质量部门的人“玩”，大家都有“对付”而不是“配合”质量部门的心态。
有一次质量部门要检查某个重点项目的文档，偏偏这个项目是保密的，一方要检查一方要保密，双方弄僵了。在事业部内部开会的时候，这个重点项目的负责人大发脾气说：我最烦那些人，看么看不懂，还老是来检查，别说项目是保密的，就是不保密的我也不给看。大家火得很热烈，我就火上加油给质量部门发了email，大致意思是“你们搞ISO9000的人不懂软件工程，不懂CMM，不懂得软件开发却老是来检查软件项目，对本事业部只有干扰而没有帮助”，email言词激烈。我把email发给一位和我打交道比较多的质量部人员，并抄送给本事业部所有人员，给本部门大大地出了一口气。
过了几天，我收到质量部同事的email，足足有两页纸。有几句话我记忆很深刻：
收到你的email时我十分震惊。依你的身份，当着事业部百余名员工的面，把工作上的怨气发在我这个无辜的人的头上，我实在难以接受。
提高产品质量是我们的工作职责，我们并不想和任何人争吵。观念的差异可以通过交流、协商的方式来解决，我不强求你接受任何东西，但真心希望能对你有所触动，并欢迎你和我或我的同事继续探讨、交流。
我非常后悔，因为我伤害了一个十分友善而且敬业的质量部同事。而更糟糕的是，我这个例子只不过是冰山一角而已。我所认识的公司内外的质量人员都是性格温和、细致耐心的人，他们的优点在于人格而不是技术。平心而论，他们比技术出色但是情商不高的技术人员更值得交朋友。质量检查是他们的工作职责，谁也不会有意干扰项目，所以任何人都不应该向他们发火。
9.4.2 路在何方
我的一位同事在干了5年的质量保证工作后，终于厌倦了，到某大学软件学院当老师去了，目前看上去比较满意。
有一位生物专业毕业的、做了多年ISO9000的同事和我谈心，她也说很想当大学老师，当然不教质量管理的课程，而是希望重拾她的生物专业。
那位平白无故受我怨气的质量部同事正在读MBA，学得很好，我想她必定有更好的追求。
上节email的作者一边上班一边读工程硕士，她的工作任务有一些变动：
我已经转做测试了，主要原因有以下几个：
1、我们的过程质量虽然很好，但是在提高产品质量方面没有达到期望的效果；
2、测试是保证产品质量的一种重要手段，我要接触一下，从而对产品的质量有更好的理解；
3、这段时间项目不多，我比较空闲，而且只做SQA的工作，有点枯燥；
4、我们公司的测试力量比较薄弱，我希望能帮忙做点什么；
5、长期以来，没有深入项目的感觉，我希望自己能够亲身去执行我们的过程，看看能不能找出点问题；
同时，我也没有放弃SQA的工作，以后在做测试的同时，我会至少兼做一个项目的SQA。我想这样是一个相辅相成的过程。我希望自己能对提高软件产品质量做点贡献。
你看了email就知道她是一位积极上进的好员工，她靠自己的悟性在摸索解决问题的方法。她碰到的问题我看得很清楚，绝非个别现象。问题的根源是：她公司的领导不懂得真正有效的质量管理，使她无法发挥全职质量人员的价值。

软件行业里的人嘴上都说质量很重要，可是大多数企业并没有给质量人员提供良好的职业发展空间。质量人员通常仅给企业起到心里安慰的作用。这样下去，有能耐的质量人员会跑光的。
在大多数的软件企业里，男性处于支配地位，女性职位相对比较低。而质量人员通常是女性，很多男性主管从未真正地把质量人员当成企业的宝贵人才看待，这种偏见是非常有害的。任何素质合格的员工都是宝贵的人才，很多默默无闻的人才其实是被不懂得管理的领导给荒废了。质量人员之所以没有发挥预期的效果，不是性别缘故，主要过失在于领导者。企业领导们要好好反省，你自己不懂质量管理，不是瞎指挥吗？
我的建议如下：
（1）无论是企业领导还是质量人员，都要好好学习全面软件质量管理方法，结合企业的特点给出真正有效的质量管理方案。
（2）只有当企业领导采用了正确的质量管理方案，用了合格的质量人员，才可能看得到比较明显的质量改善，才能形成良性循环。
（3）如果想让质量人员负起比较重的责任，那么就要给她相应的权力。在企业中，责任和权利是成正比的。如果质量人员的地位无足轻重，那么必然导致质量管理无足轻重。
（4）给质量人员一个适宜的升迁机会和薪资待遇，让她能够快乐地工作，而不是成天无奈地检查质量。
9.4.3 赞美诗
在我写这本书的时候，中国正遭受非典型肺炎（SARS）的肆虐。人们在危难之际想起了医护人员的好处，因此涌现了许多对医护人员的赞美诗。
我碰巧在网上搜索到一位软件诗人献给质量人员的赞美诗“晚上八九点钟的太阳”，我看了不禁喜悦和感动。我认为没有必要等到软件质量灾难降临的时候才想起质量人员，于是摘录这首诗公布于此。诗中的“狼人”和“银弹”是软件工程的典故，寓意深刻。衷心感谢这位不知姓名的浪漫软件诗人。

晚上八九点钟的太阳
——献给软件测试和质保人员

我更喜爱晚上八九点钟的太阳，
虽然人们都已把他遗忘，
但他还是艰难地悬挂在天上。

我更喜爱晚上八九点钟的太阳，
因为他将奏出黎明的交响。
没有他
又怎会呼唤出一片明亮？

我更喜爱晚上八九点钟的太阳，
因为他会化成早上的朝阳。
没有他
又怎会有什么希望？

我更喜爱晚上八九点钟的太阳，
因为他是上帝的臂膀。
没有他，
又怎会创造万物的光芒。

狼人望月嚎叫，
它知道
月亮映出的太阳之光，
终将化为银弹，
射入它的胸膛。

我
更喜爱
晚上八九点种的太阳。
9.5 全面软件质量管理
9.5.1 模型
如果一个人浑身上下都没有毛病，那么他就很健康；反之如果浑身是病，那么就不健康。所以毛病是健康的死对头。
同理，质量的死对头是缺陷，缺陷是混在产品中的人们不喜欢、不想要的东西，它对产品没有好处只有坏处。人们常说的Bug就是缺陷的形象比喻。
显然，缺陷越多质量越低，缺陷越少质量越高，提高软件质量的基本手段是消除软件缺陷。让我们看看中国郎中治病的故事，受点启发。
在中国古代，有一家三兄弟全是郎中。其中有一人是名医，人们问他：“你们兄弟三人谁的医术最高？”
他回答说：“我常用猛药给病危者医治，偶尔有些病危者被我救活，于是我的医术远近闻名并成了名医。我二哥通常在人们刚刚生病的时候马上就治愈他们，临近村庄的人说他是好郎中。我大哥不外出治病，他深知人们生病的原因，所以能够预防家里人生病，他的医术只有我们家里才知道。”
上述故事里，郎中三兄弟是三种治病方式的代言人。相似地，提高软件质量也有三种方式。
老大治病的方式最高明，如果人们能够预防生病的话，那么没病就用不着看医生了。提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。
即使一个人严守养生之道，身体状况良好，但总是会意外地得病的，得了病就要去看医生。老二治病的方式就是医院的模式，病人越早看病，就越早治好，治病的代价就越低。同理，在开发软件的时候，即使人们的技术水平很高，并且严格遵守规范，但是人非机器，总是会犯错误的，因此无法完全避免软件中的缺陷。那么怎么办呢？
当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。这种方式效果比较好，人们一般都能学会。最常用的方法是技术评审、软件测试和过程检查，已经被企业广泛采用并取得了成效。
老三治病的方式代价最高，只能是不得已而为之。可在现实之中，大多数软件企业采用老三的方式来对付质量问题。典型现象是：在软件交付之前，没有及时消除缺陷。当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。可笑的是，当软件系统在用户那里出故障了，那些现场补救成功的人倒成了英雄，好心用户甚至还寄来感谢信。
借鉴老大、老二治病的方法，我们提炼出全面软件质量管理的模型，如图9-1所示。项目中的所有人员几乎都参与了质量活动，只是介入的程度不同而已，本章后面几节将逐一介绍这些质量活动。

软件过程改进：提高软件技术水平和规范化水平
软件项目X
软件测试
过程检查
技术评审
缺陷
跟踪
制定质量计划

图9-1 全面软件质量管理的模型
9.5.2 质量人员的职责
谁对软件质量负责？
是全员负责。任何与软件开发、管理工作相关的人员都对质量产生影响，都要对质量负责。所以人们不要把质量问题全部推出质量人员或测试人员。
谁对软件质量负最大的责任？
谁的权利越大，他所负的质量责任就越大。质量人员是成天与质量打交道的人，但他个人并不对产品质量产生最大的影响，所以也不负最大的责任。
前面分析过了，如果质量人员仅仅从事质量保证活动的话，那么他对软件开发和管理的介入就非常肤浅，对提高质量缺乏实质性贡献，最终导致他很“郁闷”。
在图9-1的模型中，质量人员的主要职责是：
² 负责制定质量计划（很重要但是工作量比较少）；
² 负责过程检查（类似于CMM中的质量保证），约占个人工作量的20%；
² 参与技术评审，约占个人工作量的30%；
² 参与软件测试，约占个人工作量的30%；
² 参与软件过程改进（面向整个机构），约占个人工作量的20%；
上述工作量的比例仅供参考，在实际应用时必须根据项目的特征而定。

技术评审与软件测试关注的是产品质量而不是过程质量，两者的技术强度比过程检查要高得多，更加容易发现缺陷。技术评审和软件测试能弥补过程检查的不足，我们不能将过程检查、技术评审和软件测试的观念混为一谈，但是也不能把三者孤立起来。质量人员除了过程检查之外，还要参加（并监督）重要的技术评审和测试工作，这样做才富有成效。
软件过程改进是面向整个机构的，而不仅仅是针对某个项目的。由于质量人员的日常工作主要是过程检查、技术评审、软件测试，成天与质量问题打交道，所以他能发现整个机构的共性质量问题，因此质量人员参与软件过程改进是很有意义的。
软件过程改进一般由SEPG（Software Engineering Process Group）负责。我曾经和不少CMM咨询师和SEPG的负责人交流过，多数人认为SEPG是“立法机构”，质量小组是“执法机构”，两者应该彻底分开。我认为这种设想很不适合中国中小型软件机构（100人以下），企业又不是国家政法机构，哪有那么多的人和钱去搞理想主义啊！
图9-1的模型完全出于实用主义，所以不受ISO9000和CMM的约束。
9.5.3 制定质量计划
质量计划就是为了实现质量目标的计划。而质量目标则是由商业目标决定的。开发软件产品的最终目的是为了赚钱，所以人们为提高软件质量所付出的代价是有上限的，项目负责人当然希望代价越低越好。质量计划就是全面质量管理的行动纲领。
谁制定质量计划？
由项目核心成员和质量人员共同协商制定，主要由质量人员起草，由项目经理审批即可。
表9-2为软件质量计划的参考模板。

XXX软件质量计划
1. 质量要素分析
提示：从商业利益和技术角度判断哪些质量属性是本软件的质量要素，说明为什么，这样相关人员可以把精力集中在改善质量要素上。
质量要素
优先级
解释

2. 质量目标
提示：给出各个质量要素的恰当目标，既要使客户感到满意，又要使开发方承受得起。
质量要素
目标

3. 人员与职责
提示：项目中的许多人员将参与各种质量活动，说明他们的职责。
人员
质量活动、职责描述

4. 过程检查计划
过程域、主要检查项
时间或频度
负责人

5. 技术评审计划
待评审的工作成果
评审时间
负责人

6. 软件测试计划
测试活动名称
时间
负责人

7. 缺陷跟踪工具
提示：说明本项目采用何种缺陷跟踪工具，以及简要的使用约定。
8. 审批意见
提示：项目经理审批本计划

表9-2 软件质量计划的模板
9.5.4 技术评审
技术评审（Technical Review, TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。
技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。
技术评审的主要好处有：
² 通过消除工作成果的缺陷而提高产品的质量；
² 技术评审可以在任何开发阶段执行，不必等到软件可以运行之际，越早消除缺陷就越能降低开发成本；
² 开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。

技术评审有两种基本类型：
² 正式技术评审（FTR）。FTR比较严格，需要举行评审会议，参加评审会议的人员比较多。
² 非正式技术评审（ITR）。ITR的形式比较灵活，通常在同伴之间开展，不必举行评审会议，评审人员比较少。
理论上讲，为了确保产品的质量，产品的所有工作成果都应当接受技术评审。现实中，为了节约时间，允许人们有选择地对工作成果进行技术评审。技术评审方式也视工作成果的重要性和复杂性而定。将重要性、复杂性各分“高、中、低”3个等级。重要性－复杂性组合与技术评审方式的对应关系如表9-3所示。在制定质量计划的时候，应该确定技术评审计划，见表9-2。

重要性－复杂性组合
技术评审方式（FTR, ITR）
高高
FTR
高中
FTR
高低
FTR 或者ITR均可
中中
FTR 或者ITR均可
中低
ITR
低低
ITR
表9-3 重要性－复杂性组合与技术评审方式的对应关系

本节重点介绍正式技术评审的流程，如图9-2所示。
2.5会议结束决议
2.4讨论缺陷解决方案
2.3识别缺陷和答辩
2.2作者介绍工作成果
2.1主持人宣讲
Step1. 准备评审
Step3. 跟踪与审核
Step2. 举行评审会议

图9-2 正式技术评审的流程

第一步 准备评审
² 评审主持人首先确定评审会议的时间、地点、设备和参加会议的人员名单（包括评审员、记录员、作者、旁听者等），并告知所有相关人员（例如email）。
² 评审主持人把工作成果及相关材料、技术评审规程、检查表等发给评审员。
² 评审员阅读（了解）工作成果及相关材料。
第二步 举行评审会议
² [Step2.1] 主持人宣讲本次评审会议的议程、重点、原则、时间限制等。
² [Step2.2] 作者扼要地介绍工作成果。
² [Step2.3] 评审员根据“检查表”认真查找工作成果的缺陷。作者回答评审员的问题，双方要对每个缺陷达成共识（避免误解）。
² [Step2.4] 作者和评审员共同讨论缺陷的解决方案。对于当场难以解决的问题，由主持人决定“是否有必要继续讨论”或者“另定时间再讨论”。
² [Step2.5] 评审小组给出评审结论和意见，主持人签字后本次会议结束。评审结论有三种：
（1） 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。
（2） 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。
（3） 工作成果基本合格，需要作少量的修改，之后通过审核即可，转向第三步。
第三步 跟踪与审核
² 作者修正工作成果，消除已发现的缺陷。评审主持人（或者指定审查员）跟踪每个缺陷的状态。直到工作成果合格为止。
技术评审报告的模板如表9-4所示。

XXX技术评审报告
1. 基本信息
提示：由评审主持人或记录员填写
成果介绍
名称，版本，作者，时间等等
评审时间

评审地点

评审会议名单
角色、职务
人员A
评审主持人
人员B

…

2. 问答记录
提示：由评审主持人或记录员填写，主要记录评审过程中的疑问、答复、争论、处理意见
记录A

记录B

…

3. 评审结论与意见
提示：由评审主持人填写
评审结论
[ ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。
[√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。
[ ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。
意见建议

签字
主持人签字

4. 缺陷跟踪与审核
提示：如果使用了缺陷跟踪软件，那么无需手工填写此表，用软件生成缺陷报表就行。
缺陷描述
缺陷解决方案、结果

表9-4 技术评审报告的模板

技术评审是个团体活动，一般地，机构没有专职地技术评审人员，当需要技术评审的时候临时组织人员就可以了。质量人员一定要参与技术评审活动（大约占其工作量的30％左右），建议让质量人员主持那些重要的技术评审会议，免得开发人员忘记了技术评审。
9.5.5 软件测试
技术评审和软件测试的目的都是为了消除软件的缺陷，两者的主要区别是：前者无需运行软件，评审人员和作者把工作成果摆放在桌面上讨论；而后者一定要运行软件来查找缺陷。技术评审在软件测试之前执行，尤其是在需求开发和系统设计阶段。相比而言，软件测试的工作量通常比技术评审的大，发现的缺陷也更多。
本书第7章已经深入介绍了软件测试的方法与技术，本节不再累赘。这里要着重强调的是，软件测试、技术评审、过程检查、缺陷跟踪都是全面质量管理不可缺少的组成部分。在制定质量计划的时候，已经确定了本项目的主要测试活动、时间和负责人，之后再考虑软件测试的详细计划和测试用例。
如果机构没有专职的软件测试人员的话，那么开发人员可以兼职做测试工作。当项目开发到后期，过程检查和技术评审都已经没有多少意义了，开发小组急需有人帮助他们测试软件，如果质量人员参与软件测试，对开发小组而言简直就是“雪中送炭”。
本章强调，质量人员一定要参与软件测试（大约占其工作量的30％左右），只有这样他才能深入地了解软件的质量问题，而且给予开发小组强有力地帮助。
9.5.6 过程检查
CMM和ISO9001所述的软件质量保证，实质就是过程检查，即检查软件项目的“工作过程和工作成果”是否符合既定的规范。
“过程检查”这个词虽然没有质量保证那么动听，但是其含义直接明了，不会让人误解。为了避免人们误以为“质量保证”能够“保证质量”，我提议用“过程检查”取代质量保证这个术语。
虽然本章批判了“质量保证”的浮夸，但是并没有全盘否定质量保证的好处。过程检查对提高软件质量是有帮助的，只是它的好处没有象质量保证鼓吹的那么好而已。
例如，机构制定了配置管理规范，要求每个项目都进行版本控制，但是在项目的实际开发过程中，许多开发人员并没有对其工作成果进行版本控制。万一版本发生混乱，必定对项目产生负面影响。如果质量人员在过程检查时发现了这个问题，那么他就有责任要求开发人员执行版本控制，如果开发人员不接受这个好意，那么质量人员就要向上级领导反映这个问题，直至消除隐患为止。
再例如，机构制定了重要工作成果的文档模板（例如需求规格说明书、设计报告等），要求开发人员写的文档尽可能符合模板。如果质量人员发现开发人员写的文档与机构的模板差异非常大，那么就要搞清楚究竟是模板不合适？还是开发人员偷工减料大大简化了模板？
符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果十有八九是质量不合格的。
过程检查的要点是：找出明显不符合规范的工作过程和工作成果，及时指导开发人员纠正问题，切勿吹毛求疵或者在无关痛痒的地方查来查去。
不少机构的质量人员并没有真正理解过程检查的意义，老是对照规范，查找错别字、标点符号、排版格式等问题，迷失了方向，这样只有疲劳没有功劳，而且让开发人员很厌烦。对于中小型项目而言，过程检查工作由质量人员一个人负责就够了，约占其20％的工作量，让质量人员抽出更多的时间从事技术评审和软件测试工作。

制定过程检查计划
周期性过程检查
解决问题

图9-3 过程检查的流程

过程检查计划的要点是确定主要检查项和检查时间（或频度），切勿进行事无巨细的检查。
质量人员在执行过程检查的时候，如果发现问题，应该立即记录下来。过程问题也是缺陷，因此最好使用缺陷跟踪工具，有助于提高过程检查的效率。
质量人员首先设法在项目内部解决已经发现的质量问题，与项目成员们协商，给出解决措施。在项目内难以解决的质量问题，由上级领导给出解决措施。
9.5.7 缺陷跟踪工具
如果没有缺陷跟踪工具的话，人们只好用纸张或文件去记录缺陷，不仅变更缺陷信息很麻烦，而且难以共享信息。缺陷跟踪工具就是帮助项目成员记录和跟踪缺陷用的，一般都有数据库支持，可以在局域网内运行。
Internet上有许多缺陷跟踪工具，大家可以免费下载使用。由于缺陷跟踪工具仅仅是一种辅助性的工具，我们没有必要太在乎该软件的功能，只要用起来方便就行。

一般地，缺陷的属性如表9-5所示，其中“*”表示必需属性。
缺陷属性
描述
* 缺陷ID
给每个缺陷分配唯一的ID，编号应当有规律，最好能够反映缺陷类型。
* 缺陷类型
给缺陷划分一些类型，便于统计，常见类型有需求缺陷、设计缺陷、代码缺陷、界面缺陷、文档缺陷等等
* 缺陷状态
常用缺陷状态有：新缺陷、缺陷再现、已经解决、不做处理
* 缺陷描述
用一段文字描述缺陷
相关文件
给出与本缺陷相关的文件
* 严重性
划分缺陷的严重性，例如3-严重，2-中等，1-轻微
* 优先级
划分处理缺陷的优先级，例如3－高，2－中，1－低
* 报告者
即报告这个缺陷的人
* 报告日期
给出报告这个缺陷的日期
* 接受者
把缺陷指派给某些人处理
解决方案（建议）
如何人都可以给出解决这个缺陷的建议
解决日期
记录解决缺陷的日期
表9-5 缺陷的属性

缺陷跟踪工具的常见功能如表9-6所示。

常见功能
描述
查询缺陷
可以根据缺陷类型、缺陷状态、优先级、报告者、报告日期等条件查询缺陷。
添加缺陷
可以添加新的缺陷
修改缺陷
可以修改缺陷的信息
删除
被授权的用户可以删除某些缺陷
缺陷分类图
绘制缺陷的分类图（例如饼图）
缺陷趋势图
绘制缺陷的趋势图
Email
如果缺陷信息发生变动（添加和修改），那么自动发email给报告者和接受者。
表9-6 缺陷跟踪工具的常见功能