软件全面质量管理的思想体系

一：软件质量管理的基本概念

软件质量就是软件与用户需求相一致的程度。具体地说，软件质量是软件符合明确叙述的功能和性能需求、以及所有专业开发的软件都应具有的隐含特征的程度。
用户需求是衡量软件质量的基础。
除满足明确定义的需求外，还要满足隐含的需求。

1.软件的质量属性和质量要素

（1）质量属性

软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们通过改善软件的各种质量属性，从而提高软件的整体质量（否则无从下手）。
软件的质量属性很多，如正确性、精确性，健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等。这些质量属性又可以分为功能性和非功能性两大类。

（2）质量要素

质量要素，应该理解为能够提高用户满意度和提高产品核心竞争力和价值的质量属性。如果某些质量属性并不能产生显著的经济效益，我们可以忽略它们，把精力用在对经济效益贡献最大的质量要素上。简而言之，只有质量要素才值得开发人员下功夫去改善。

功能性质量要素:正确性，健壮性，可靠性
非功能性质量因素：性能，易用性，安全性，可扩展性，兼容性，可移植性
a.正确性:第一重要，机器不会欺骗人，软件运行错误都是人为造成的。
b.健壮性:包括容错能力和恢复能力，开发过程中应该充分考虑各种异常和边界。
c.可靠性:可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。
d.性能：性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。(性能问题解决根本还是算法和程序的优化，而不是期待硬件的更高配置)
e.易用性:易用性是指用户使用软件的容易程度。(界面友好仅仅是一方面，还包括人机工程很多内容)
f.安全性:安全性是指防止系统被非法入侵的能力
g.扩展性:反映了软件应对变化的能力
h.兼容性:对硬件的兼容，对软件的兼容
非功能性需求是软件质量重要组成，是架构设计和软件产品化的重要考虑，但往往容易被忽视。特别是在开发通用性的产品的时候，非功能性质量要素必须要考虑全面。

2.商业目标决定质量目标

重视软件质量是应该的，但是“质量越高越好”并不是普适的真理。只有极少数软件应该追求“零缺陷”，对绝大多数软件而言，商业目标决定了质量目标，而不该把质量目标凌驾于商业目标之上。

企业的根本目标是为了获取尽可能多的利润，而不是生产完美无缺的产品。如果企业销售出去的软件的质量比较差，轻则挨骂，重则被退货甚至被索赔，因此为了提高用户对产品的满意度，企业必须提高产品的质量。但是企业不可能为了追求完美的质量而不惜一切代价，当企业为提高质量所付出的代价超过销售收益时，这个产品已经没有商业价值了，还不如不开发。

企业必须权衡质量、效率和成本，产品质量太低了或者太高了，都不利于企业获取利润。企业理想的质量目标不是“零缺陷”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。

3.质量保证保证

软件质量保证（Quality Assurance）的目的是为管理者提供有关软件过程和产品的适当的可视性。它包括评审和审核软件产品及其活动，以验证其是否遵守既定的规程和标准，并向有关负责人汇报评审和审核的结果。

简而言之，质量保证活动就是检查软件项目的“工作过程和工作成果”是否符合既定的规范。如此简单的活动为什么被冠以“质量保证”这等份量的术语呢？没有历史典故，经我考究，猜想是源于一个天真的假设：

过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”，而“差的过程”将产生“差的产品”。假设企业已经制定了软件过程规范，如果质量保证人员发现某些项目的“工作过程以及工作成果”不符合既定的规范，那么马上可以断定产品存在缺陷。反之，如果质量保证人员没有发现不符合既定规范的东西，那么也可以断定产品是合格的。

符合既定规范的东西并不意味着质量一定合格，仅靠规范无法识别出产品中可能存在的大量缺陷.

4.全面软件质量管理模型

提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。

其次方法是当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。这种方式效果比较好，人们一般都能学会。最常用的方法是技术评审、软件测试和过程检查，已经被企业广泛采用并取得了成效。

最差的是在软件交付之前，没有及时消除缺陷。当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。可笑的是，当软件系统在用户那里出故障了，那些现场补救成功的人倒成了英雄，好心用户甚至还寄来感谢信。

谁对软件质量负责？是全员负责。任何与软件开发、管理工作相关的人员都对质量产生影响，都要对质量负责。所以人们不要把质量问题全部推出质量人员或测试人员。

谁对软件质量负最大的责任？谁的权利越大，他所负的质量责任就越大。质量人员是成天与质量打交道的人，但他个人并不对产品质量产生最大的影响，所以也不负最大的责任。

5.技术评审

技术评审（Technical Review, TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。
技术评审的主要对象：需求和设计规格说明、代码、测试计划、用户手册等。

（1）正式和非正式技术评审

技术评审分为正式技术评审和非正式技术评审两种基本类型，前者比较严格，需要举行评审会议，参加人员比较多，后者的形式比较灵活，通常在同伴之间开展，不必举行评审会议，参与人员相对较少。
一般来说，对重要性和复杂性较高的工作成果，应进行正式技术评审，对重要性和复杂性相对较低的工作成果，可进行非正式技术评审。

（2）技术评审会议

技术评审以会议形式进行，一般有如下约束： 评审会议通常由3~5人参加。 会议之前评审人员要做准备，但每人的准备时间不超过2个小时。
评审会议的时间不超过2个小时。 一次技术评审只关注软件的某一特定部分（例如需求或设计规格说明的一部分）。缩小评审焦点可提高发现错误的可能性。

（3）正式技术评审流程

评审组长把待评审的材料分发给每个评审者，评审者（包括评审组长）审查材料，记下相关的要点，为评审会议做准备。
开评审会议。评审会议由评审组长、评审者、评审对象的开发者参加。其中的一个评审者充当记录员，负责记录会议中发现的所有问题。
由开发小组对提交的评审对象进行讲解。同时评审者可对开发者提问，提出建议和要求，展开讨论。 在讨论中如果发现了问题和错误，由记录员记录下来。
会议结束时必须做出以下三个决策之一： 接受该产品，不需要做修改。 由于错误严重，拒绝接受。等到错误改正后，还要进行另一次评审。
暂时接受该产品，但需要对某一部分进行修改，修改后不需要再进行另一次评审。 决定作出后，所有参加会议的人员签字，确认会议结果。
技术评审会议后，要完成一个“评审总结报告”，其内容包括：评审对象是什么？谁参加了评审？评审的结论是什么？有哪些重要发现？
评审会议上所记录的问题列表通常作为评审总结报告的附件。
跟踪与审核。开发者修改工作成果，消除已发现的缺陷。由指定的审查人员跟踪每个缺陷的状态，直到工作成果合格为止。

（4）技术评审的注意事项

评审产品，而不是评审人。评审会议的气氛要轻松和愉快，注意提出问题时的方式和态度，不要让产品开发者产生被审问的感受。
制订评审会议的议程并遵守进度。不要让会议过分拖延。问题的具体解决方案可以在会后讨论。
使用检查清单。为不同的软件产品（需求、设计、代码等）开发检查清单，在检查清单中列出所有重要的、常见的问题，这样可以使评审会议聚焦于一些重要问题。

（5）代码评审（Code Review）

编码阶段的一种技术评审，由一组人员对程序进行阅读和静态分析，有效地检查程序代码中的缺陷。
评审内容：程序是否符合编码规范，程序结构是否合理，算法和程序逻辑是否正确，程序性能怎样等。 很多程序逻辑错误很难通过测试发现。

二：软件质量特性

1.软件质量特性– 功能性

适合性:与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性准确性:与能否得到正确或相符的结果或效果有关的软件属性互用性:与同其他指定系统进行交互的能力有关的软件属性
依从性:使软件遵循有关的标准,约定,法规及类似规定的软件属性
安全性:与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性

2.软件质量特性– 可靠性

成熟性:与由软件故障引起失效的频度有关的软件属性
容错性:与在软件故障或违反指定接口的情况下,维持规定的性能水平的能力有关的软件属性
易恢复性:与在失效发生后,重建其性能水平并恢复直接受影响数据的能力以及为达此目的所需的时间和能力有关的软件属性

3.软件质量特性– 易用性

易理解性:与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性
易学性:与用户为学习软件应用所花的努力有关的软件属性
易操作性:与用户为操作和运行控制所花努力有关的软件属性

4.软件质量特性– 效率

时间特性:与软件执行其功能时响应和处理时间以及吞吐量有关的软件属性
资源特性:与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性

5.软件质量特性– 可维护性

易分析性:与为诊断缺陷或失效原因及为判定待修改的部分所需努力有关的软件属性
易改变性:与进行修改,排除错误或适应环境变化所需努力有关的软件属性
稳定性:与修改所造成的未预料结果的风险有关的软件属性易测试性:与确认已修改软件所需的努力有关的软件属性

6.软件质量特性– 可移植性

适应性:与软件无需采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性
易安装性:与在指定环境下安装软件所需努力有关的软件属性
遵循性:使软件遵循与可移植性有关的标准或约定的软件属性
易替换性:与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的软件属性

三：软件质量的常用度量

初期故障率：指软件在初期故障期（一般以软件交付给用户后的三个月内为初期故障期）内单位时间的故障数。
用来评价交付使用的软件的质量，预测什么时候软件运行达到基本稳定。
一般以每100小时的故障数为单位。

偶然故障率：指软件在偶然故障期（一般以软件交付给用户后的4个月以后为偶然故障期）内单位时间的故障数。
它用来度量软件处于稳定状态下的质量。
一般以每1000小时的故障数为单位。

平均失效前时间（Mean Time to Failure，MTTF）：指软件在失效前（两次失效之间）正常工作的平均统计时间。
用来度量软件的可靠性。

平均修复时间（Mean Time to Reparation，MTTR）：指软件失效后，使其恢复正常工作所需要的平均统计时间。
用来度量软件的可维护性。

缺陷密度:指软件单位数量的源代码隐藏的缺陷数量