软件质量管理
8.1质量的概念
8.1.1如何描述质量◆词典对质量的定义是：①典型的或本质的特征；②事物固有的或区别于其他事物的特征或本质；③优良或出色的程度。
◆CMM对质量的定义是：①一个系统、组件或过程符合 特定需求的程度；②一个系统、组件或过程符合 客户或用户的要求或期望的程度。
可以这样理解软件质量： 软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。
人们通过改善软件的各种质量属性，从而提高软件的整体质量. 软件的质量属性很多，如:正确性、精确性，健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等。
8.1.2十大软件质量因素 有必要对质量属性做些分类和整合。
质量属性可分为两大类： “功能性”与“非功能性”，后者有时也称为“能力”（Capability） ◆功能性质量因素：正确性，健壮性，可靠性 ◆非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性 8.1.3软件质量要素 ◆什么是软件质量要素？ –
（1）从技术角度讲，对软件整体质量影响最大的那些质量属性才是质量要素； –
（2）从商业角度讲，客户最关心的、能成为卖点的质量属性才是质量要素。
►在根据对象的可度量特征考察一个对象时，可以有以下两种不同的质量：设计质量和符合质量。
►设计质量：是指设计者为一件产品规定的特征。
材料等级、耐久性、及性能的规约都属于设计质量。
如果产品能够依照规约进行制造，则产品的设计质量便会提高。
►符合质量：是指在制造过程中符合设计规格的程度。
同样，符合程度越高，符合质量也就越高。
►在软件开发时，设计质量包括系统的需求、规约和设计。
►符合质量则主要关注实现问题。
如果实现了符合设计、得到的系统满足系统需求和性能目标，则符合质量较高. 对于一个特定的软件而言，我们要首先判断： 什么是质量要素，才能给出提高质量的具体措施; 而不是一股脑地想把所有的质量属性都做好; 否则不仅做不好，还可能得不偿失。
1)正确性◆正确性是指软件按照需求正确执行任务的能力。
“正确性”的语义涵盖了“精确性”。
◆正确性无疑是第一重要的软件质量属性。
◆技术评审和测试的第一关都是检查工作成果的正确性。
◆机器不会主动欺骗人，软件运行出错通常都是人造成的，所以不要找借口埋怨机器有毛病。
2)健壮性◆健壮性是指在异常情况下，软件能够正常运行的能力。
◆正确性描述软件在需求范围之内的行为，而健壮性描述软件在需求范围之外的行为。
◆开发者往往把异常情况错当成正常情况而不作处理，结果降低了健壮性。
◆健壮性有两层含义：一是容错能力，二是恢复能力。
–从语义上理解，恢复不及容错那么健壮。
–Unix容错能力很强，可惜不好用。
–Windows容错能力较差，但是恢复能力很好，而且很好用。
占了90%的操作系统市场。
用户才不管正确性与健壮性的区别，反正软件出了差错都是开发方的错。
所以提高软件的健壮性也是开发者的义务。
3)可靠性 ◆可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。
◆可靠性本来是硬件领域的术语。
比如某个电子设备在刚开始工作时挺好的，但由于器件在工作中其物理性质会发生变化（如发热），慢慢地系统的功能或性能就会失常。
所以一个从设计到生产完全正确的硬件系统，在工作中未必就是可靠的。
◆软件在运行时不会发生物理性质的变化，人们常以为如果软件的某个功能是正确的，那么它一辈子都是正确的。
◆可是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。
◆平时软件运行得好好的，说不准哪一天就不正常了，如有千年等一回的“千年虫”问题，司空见惯的“内存泄露”、“误差累积”问题等等。
◆软件可靠性分析通常采用统计方法，遗憾的是目前可供第一线开发人员使用的成果很少见，大多数文章限于理论研究。
◆口语中的可靠性含义宽泛，几乎囊括了正确性、健壮性。
只要人们发现系统有毛病，便归结为可靠性差。
从专业角度讲，这种说法是确切的。
◆软件可靠性问题主要是在编程时候埋下的祸害（很难测试出来），应当提倡规范化程序设计，预防可靠性祸害。
◆时隐时现的错误一般都属于可靠性问题，纠错的代价很高。
例如当维护人员十万火急地赶到现场时，错误消失了；等维护人员回家后，错误又出现了。
►可靠性的简单度量是“平均失败间隔时间”(MTBF)，其中： ►MTBF=MTTF+MTTR►(MTTF和MTTR分别是“平均失败时间”和 “平均修复时间”的首字母缩写)。
►许多研究人员认为MTBF是一个远比“缺陷 数/KLOC”更为有用的度量指标。
►简而言之，最终用户关心的是失败，而不是总缺陷数。
►由于一个程序中包含的每个缺陷所具有的失败率不同，总缺陷数难以表示系统的可靠性. ►我们必须开发一个“可用性”度量。
►软件可用性是指在某个给定时间点上程序能够按照需求执行的概率。
其定义为： ►可用性=MTTF/(MTTF+MTTR)×100％►MTBF可靠性度量对MTTF和MTTR同样敏感。
►(MTTF和MTTR分别是“平均失败时间”和 “平均修复时间”的首字母缩写)。
►而可用性度量在某种程度上对MTTR较为敏 感，MTTR是软件可维护性的间接度量。
4)性能 ◆性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。
人们总希望软件的运行速度高些，并且占用资源少些。
既要马儿跑得快，又要马儿吃的少。
◆性能优化的关键工作是找出限制性能的“瓶颈”，不要在无关痛痒的地方瞎忙乎。
–程序员可以通过优化数据结构、算法和代码来提高软件的性能。
例如数据库程序的优化。
–算法复杂度分析是很好的方法，可以达到“未卜先知”的功效。
◆性能优化就好像从海绵里挤水一样，你不挤，水就不出来，你越挤海绵越干。
◆有些程序员认为现在的计算机不仅速度越来越高，而且内存越来越大，因此软件性能优化的必要性下降了。
◆这种看法是不对的，殊不知随着机器的升级，软件系统也越来越庞大了和复杂了，性能优化仍然大有必要。
5)易用性◆易用性是指用户使用软件的容易程度。
◆现代人的生活节奏快，干啥事都想图个方便。
所以把易用性作为重要的质量属性对待无可非议。
软件的易用性要让用户来评价。
当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“界面友好”、“方便易用”等词来评价软件产品。
6)清晰性 ◆清晰意味着所有的工作成果易读、易理解，可以提高团队开发效率，降低维护代价。
◆开发人员只有在自己思路清晰的时候才可能写出让别人易读、易理解的程序和文档。
◆可理解的东西通常是简洁的。
一个原始问题可能很复杂，但高水平的人就能够把软件系统设计得很简洁。
7)安全性◆这里安全性是指信息安全，英文是Security而不是Safety。
◆安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。
◆信息安全是一门比较深奥的学问，其发展是建立在正义与邪恶的斗争之上。
◆开发商和客户愿意为提高安全性而投入的资金是有限的，他们要考虑值不值得。
◆究竟什么样的安全性是令人满意的呢？ –一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、风险等因素）高于得到的好处，那么这样的系统可以认为是安全的。
–对于普通软件，并不一点要追求很高的安全性，也不能完全忽视安全性，要先分析黑客行为。
8)可扩展性 ◆可扩展性反映软件适应“变化”的能力。
◆在软件开发过程中，“变化”是司空见惯的事情，如需求、设计的变化，算法的改进，程序的变化等等。
◆由于软件是“软”的，是否它天生就容易修改以适应“变化”？关键要看软件的规模和复杂性。
–如果软件规模很小，问题很简单，那么修改起来的确比较容易，这时就无所谓“可扩展性”了。
要是软件的代码只有100行，那么“软件工程”也就用不着了。
–如果软件规模很大，问题很复杂，倘若软件的可扩展性不好，那么该软件就像用卡片造成的房子，抽出或者塞进去一张卡片都有可能使房子倒塌。
现代软件产品通常采用“增量开发模式”，不断推出新版本，获取增值利润。
可扩展性越来越重要。
可扩展性是系统设计阶段重点考虑的质量属性。
现代软件产品通常采用“增量开发模式”，不断推出新版本，获取增值利润。
可扩展性越来越重要。
可扩展性是系统设计阶段重点考虑的质量属性。
谈到软件的可扩展性，开发人员首先想到的是怎样提高可扩展性，于是努力去设计很好的体系结构来提高可扩展性，却不考虑该不该做这件事。
从商业角度考虑，如果某个软件将不断地推出新版本，那么可扩展性很重要。
但是如果软件永远都不会有下个版本（一次性买卖），那么根本无需提高可扩展性，何必自找苦吃呢！ 9)兼容性 ◆兼容性是指不同产品（或者新老产品）相互交换信息的能力。
例如两个字处理软件的文件格式兼容，那么它们都可以操作对方的文件，这种能力对用户很有好处。
◆兼容性的商业规则：弱者设法与强者兼容，否则无容身之地；强者应当避免被兼容，否则市场将被瓜分。
10)可移植性 ◆软件的可移植性指的是软件不经修改或稍加修改就可以运行于不同软硬件环境（CPU、OS和编译器）的能力，主要体现为代码的可移植性。
–编程语言越低级，用它编写的程序越难移植，反之则越容易。
–这是因为，不同的硬件体系结构（例如IntelCPU和SPARCCPU）使用不同的指令集和字长，而OS和编译器可以屏蔽这种差异，所以高级语言的可移植性更好 –Java程序号称“一次编译，到处运行”，具有100%的可移植性。
–为了提高Java程序的性能，最新的Java标准允许人们使用一些与平台相关的优化技术，这样优化后的Java程序虽然不能“一次编译，到处运行”，仍然能够“一次编程，到处编译”。
◆软件设计时应该将“设备相关程序”与“设备无关程序”分开，将“功能模块”与“用户界面”分开。
8.1.4质量控制 ►“质量控制”是为了保证每件工作产品都满足对它的需求而应用于整个开发周期中的一系列审查、复审和测试。
►质量控制在创建工作产品的过程中包括一个反馈循环。
►度量和反馈相结合，使得能够在得到的工作产品不能满 足其规约时调整开发过程。
►这种方法将质量控制视为整个制造过程的一部分。
►质量控制中的关键概念之一是所有工作产品都具有定义 好的和可度量的规约，可以将每个过程的产品与这一规约进行比较。
反馈循环的引入对于最小化产生的缺陷至关重要。
8.1.5质量保证 ►“质量保证”由管理层的审计和报告功能构成。
►质量保证的目标是为管理层提供有关软件项 目的过程和产品的质量信息所需的数据，从而获得产品质量是否符合预定目标的一定的可见性。
►质量保证包括评审和审核产品及其活动,以验证其是否遵守应用规程和标准.►如果质量保证所提供的数据发现了问题，则管理层负责解决这一问题，并为解决质量问题分配所需的资源。
8.1.6质量的成本 ►质量成本包括所有由质量工作或者进行与质量有关的活动所导致的成本。
►质量成本研究的开展能够为当前质量成本设定基线，标识降低质量成本的机会，并提供一种规范化的比较基础。
►质量成本可以被划分为与预防、鉴定及失败相关的成本。
►“预防成本”包括：
1.·质量计划。
2.·正式技术复审。
3.·测试设备。
4.·培训。
►“鉴定成本”包括为深入了解“首次通过”各个过程时产品的状态而开展的那些活动。
鉴定成本的例子如下：
1.·过程内和过程间审查。
2.·设备校准和维护。
3.·测试。
►“失败成本”是指如果在将产品交付给客户之前已经消除了缺陷时就不会存在的成本。
失败成本可以进一步划分为内部失败成本和外部失败成本。
►“内部失败成本”是指在产品交付之前发现错误而引发的成本。
内部失败成本包括：
1.·返工。
2.·修复。
3.·失败模式分析。
►“外部失败成本”是指与产品交付给客户之后所发 现的缺陷相关的成本。
外部失败成本的例子如下：
1.·解决客户的抱怨。
2.·退换产品。
3.·求助电话支持。
4.·保修工作。
8.2质量运动 全面质量管理(TQM)►第一步是指一个连续的过程改进系统。
目标是开发 一个看的见的、可重复的和可度量的过程。
►第二步将检查影响过程的无形因素，并优化这些因素对过程的影响。
►第三步关注产品的用户,通过检查用户使用产品的方式，而导致产品本身的改进和(潜在地)改进产品的生产过程。
►第四步将管理者的注意力从当前的产品上移开并拓宽。
这是一个面向商业的步骤，通过观察产品在市场上的用途，寻找产品在可以识别的相关领域中的发展机会。
8.2.1SQA活动 ►SQA小组的职责是辅助软件工程小组得到高质量的最终产品. ►软件质量保证的措施§CMM对软件质量保证是这8.3.样2S描QA述活动的：►软件质量保证（QualityAssurance）的目的是为管理者提供有关软件过程和产品的适当的可视性。
►它包括评审和审核软件产品及其活动，以验证其是否遵守既定的规程和标准，并向有关负责人汇报评审和审核的结果。
质量保证（QualityAssurance,QA）是CMM和ISO9001最为推崇的改善软件质量的方法。
简而言之，质量保证活动就是检查软件项目的“工作过程和工作成果”是否符合既定的规范。
过程质量与产品质量存在某种程度的因果关系， 通常“好的过程”产生“好的产品”，而“差的过程”将产生“差的产品”。
假设企业已经制定了软件过程规范，如果质量保证人员发现某些项目的“工作过程以及工作成果”不符合既定的规范，那么马上可以断定产品存在缺陷。
反之，如果质量保证人员没有发现不符合既定规范的东西，那么也可以断定产品是合格的。
符合既定规范的东西并不意味着质量一定合格，仅靠规范无法识别出产品中可能存在的大量缺陷。
◆一般而言,质量保证的技术含量是比较低，只能检查出肤浅的缺陷，不能对付有技术难度的缺陷。
◆所以单独的“质量保证”其实并不能“保证质量”。
◆质量保证对于保证质量而言只是必要的手段，而不是充分的手段。
◆软件质量管理是充满争论的话题。
被人们奉为软件质量管理圣经的CMM和ISO9001似乎并不十分奏效，现实和理想之间的差距太大。
◆经典软件工程教科书以及CMM和ISO9001一般抛开商业目标谈质量管理，本末倒置。
◆世界上还没有万能的软件质量管理圣经，所以要辨证看待CMM和ISO9000. 8.2.2商业目标决定质量目标 ◆重视软件质量是应该的，但是“质量越高越好”并不是普适的真理。
◆只有极少数软件应该追求“零缺陷”，对绝大多数软件而言，商业目标决定了质量目标，而不该把质量目标凌驾于商业目标之上。
◆重要的理念：商业目标决定质量目标。
提高软件质量的最终目的是为了赢利，而不是创造完美无缺的产品。
因此对于普通商业软件而言，并不是“质量越高越好”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。
Ø企业的根本目标是为了获取尽可能多的利润，而不是生产完美无缺的产品。
Ø如果企业销售出去的软件的质量比较差，轻则挨骂，重则被退货甚至被索赔， Ø因此，为了提高用户对产品的满意度，企业必须提高产品的质量。
Ø但是企业不可能为了追求完美的质量而不惜一切代价，当企业为提高质量所付出的代价超过销售收益时，这个产品已经没有商业价值了，还不如不开发。
§企业必须权衡质量、效率和成本，产品质量太低了或者太高了，都不利于企业获取利润。
§企业理想的质量目标不是“零缺陷”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。
8.3软件缺陷的影响 ◆质量的死对头是缺陷（defect,bug…），◆缺陷是混在产品中的人们不喜欢、不想要的东西，它对产品没有好处只有坏处。
◆缺陷越多质量越低，缺陷越少质量越高，提高软件质量的基本手段是消除软件缺陷。
►尽管发现了数以百计的不同类型的错误，但是所有错误都可以追溯到下述原因中的一个或几个：
1.·说明不完整或说明错误(IES)
2.·与客户通信中所产生的误解(MCC)
3.·故意与说明偏离(IDS)
4.·违反编程标准(VPS)
5.·数据表示有错(EDR)
6.·模块接口不一致(IMI)
7.·设计逻辑有错(EDL)
8.·不完整或错误的测试(IET)
9.·不准确或不完整的文档(IID)10.·将设计翻译成程序设计语言中的错误(PLT)11.·不清晰或不一致的人机界面(HCI)12.·杂项(MIS) 消除软件缺陷的三种方式◆提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。
主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。
–在开发软件的时候，即使人们的技术水平很高，并且严格遵守规范，但是人非机器，总是会犯错误的，因此无法完全避免软件中的缺陷。
–当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。
–这种方式效果比较好，人们一般都能学会。
最常用的方法是技术评审、软件测试和过程检查，已经被企业广泛采用并取得了成效。
可在现实之中，大多数软件企业的典型现象是： 在软件交付之前，没有及时消除缺陷。
当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。
质量人员的主要职责：1）负责制定质量计划（很重要但工作量较少）,2）负责过程检查（类似于CMM中的质量保证），约占个人工作量的20%；3）参与技术评审，约占个人工作量的30%；4）参与软件测试，约占个人工作量的30%；5）参与软件过程改进（面向整个机构），约占个人工作量的20%； 8.4制定质量管理计划 质量管理计划就是为了实现质量目标的计划。
而质量目标则是由商业目标决定的。
开发软件产品的最终目的是为了赚钱，所以人们为提高软件质量所付出的代价是有上限的， 项目负责人当然希望代价越低越好。
质量管理计划是全面质量管理的行动纲领。
谁制定质量管理计划？由项目核心成员和质量人员共同协商制定，主要由质量人员起草，由项目经理审批即可。
◆质量管理计划的主要：–
1.质量要素分析–
2.质量目标–
3.人员与职责–
4.过程检查计划–
5.技术评审计划–
6.软件测试计划–
7.缺陷跟踪工具–
8.审批意见 8.5技术评审 8.5.1概念◆技术评审（TechnicalReview,TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。
◆技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。
技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之
一。
◆技术评审的主要好处有： –通过消除工作成果的缺陷而提高产品的质量； –技术评审可以在任何开发阶段执行，不必等到软件可以运行之际，越早消除缺陷就越能降低开发成本； –开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。
◆技术评审有两种基本类型： –正式技术评审（FTR）。
FTR比较严格，需要举行评审会议，参加评审会议的人员比较多。
–非正式技术评审（ITR）。
ITR的形式比较灵活，通常在同伴之间开展，不必举行评审会议，评审人员比较少。
►正式技术复审(FTR)是一种由软件工程师进行的软件质量保证活动。
►FTR的目标是:►
(1)在软件的任何一种表示形式中发现功能、逻辑或 实现的错误；►
(2)证实经过复审的软件的确满足需求；►
(3)保证软件的表示符合预定义的标准；►
(4)得到以一种一致的方式开发的软件；►
(5)使项目更易于管理。
►由于FTR的进行使大量人员对软件系统中原本并不 熟悉的部分更为了解，起到了提高项目连续性和培训后备人员的作用。
►FTR实际上是一类复审方式，包括：►“走查”(Walkthrough)；►“审查”(Inspection)；►“轮查”(Round-robinReview)►以及其他软件小组的技术评估。
►每次FTR都以会议形式进行，只有经过适当 的计划、控制和参与，FTR才能获得成功。
►不论选择何种FTR形式，每个复审会议都应该遵守下面的约束：
1.·复审会议(通常)应该在3到5个人之间进行。
2.·应该进行提前准备，但是每人占用工作时间 应该少于2小时。
3.·复审会议时间应该不超过2小时。
►复审总结报告将回答以下问题：►
1.复审什么？►
2.由谁复审？►
3.发现了什么，结论是什么？ 8.6正式技术评审的流程 8.7技术评审与软件测试 技术评审和软件测试的目的都是为了消除软件的缺陷，两者的主要区别是：
1.前者无需运行软件，评审人员和作者把工作成果摆放在桌面上讨论；
2.而后者一定要运行软件来查找缺陷。
技术评审在软件测试之前执行，尤其是在需求开发和系统设计阶段。
3.相比而言，软件测试的工作量通常比技术评审的大，发现的缺陷也更多。
◆在制定质量计划的时候，已经确定了本项目的主要测试活动、时间和负责人，之后再考虑软件测试的详细计划和测试用例。
◆如果机构没有专职的软件测试人员的话，那么开发人员可以兼职做测试工作。
◆当项目开发到后期，过程检查和技术评审都已经没有多少意义了，开发小组急需有人帮助他们测试软件，如果质量人员参与软件测试，对开发小组而言简直就是“雪中送炭”。
◆强调：质量人员一定要参与软件测试（大约占 其工作量的30％左右），只有这样他才能深入地了解软件的质量 问题，而且给予开发小组强有力地帮助。
8.8过程检查 ◆CMM和ISO9001所述的软件质量保证，实质就是过程检查，即检查软件项目的“工作过程和工作成果”是否符合既定的规范。
◆“过程检查”这个词虽然没有质量保证那么动听，但是其含义直接明了，不会让人误解。
◆为了避免人们误以为“质量保证”能够“保证质量”，最好还是用“过程检查”取代“质量保证”这个术语。
◆过程检查对提高软件质量是有帮助的，只是它的好处没有象质量保证鼓吹的那么好而已。
◆符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果十有八九是质量不合格的。
过程检查的要点是：找出明显不符合规范的工作过程和工作 成果，及时指导开发人员纠正问题，切勿吹毛求疵或者在无关痛痒的地方查来查去。
u不少机构的质量人员并没有真正理解过程检查的意义，老是对照规范，查找错别字、标点符号、排版格式等问题，迷失了方向，这样只有疲劳没有功劳，而且让开发人员很厌烦。
u对于中小型项目而言，过程检查工作由质量人员一个人负责就够了，约占其20％的工作量，让质量人员抽出更多的时间从事技术评审和软件测试工作。
8.9流程◆过程检查计划的要点是确定主要检查项和检查时间（或频度）。
◆质量人员在执行过程检查的时候，如果发现问题，应该立即记录下来。
过程问题也是缺陷，因此最好使用缺陷跟踪工具，有助于提高过程检查的效率。
◆质量人员首先设法在项目内部解决已经发现的质量问题，与项目成员们协商，给出解决措施。
在项目内难以解决的质量问题，由上级领导给出解决措施。
8.10缺陷跟踪工具 ◆如果没有缺陷跟踪工具的话，人们只好用纸张或文件去记录缺陷，不仅变更缺陷信息很麻烦，而且难以共享信息。
◆缺陷跟踪工具就是帮助项目成员记录和跟踪缺陷用的，一般都有数据库支持，可以在局域网内运行。
上有许多缺陷跟踪工具，大家可以免费下载使用。
由于缺陷跟踪工具仅仅是一种辅助性的工具，我们没有必要太在乎该软件的功能，只要用起来方便就行。
目前的缺陷跟踪管理工具，主要有：TestDirector、ClearQuest、Bugzilla、Raid/BMS。
◆缺陷的主要属性：缺陷ID,缺陷类型,缺陷状态,缺陷描述,相 关文件,严重性,优先级,报告者,报告日期,接受者,解决方案（建议）,解决日期。
◆缺陷跟踪工具的常见功能： 查询缺陷,添加缺陷,修改缺陷,删除,缺陷分类图,缺陷趋势图,Email
◆CMM对质量的定义是：①一个系统、组件或过程符合 特定需求的程度；②一个系统、组件或过程符合 客户或用户的要求或期望的程度。
可以这样理解软件质量： 软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。
人们通过改善软件的各种质量属性，从而提高软件的整体质量. 软件的质量属性很多，如:正确性、精确性，健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等。
8.1.2十大软件质量因素 有必要对质量属性做些分类和整合。
质量属性可分为两大类： “功能性”与“非功能性”，后者有时也称为“能力”（Capability） ◆功能性质量因素：正确性，健壮性，可靠性 ◆非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性 8.1.3软件质量要素 ◆什么是软件质量要素？ –
（1）从技术角度讲，对软件整体质量影响最大的那些质量属性才是质量要素； –
（2）从商业角度讲，客户最关心的、能成为卖点的质量属性才是质量要素。
►在根据对象的可度量特征考察一个对象时，可以有以下两种不同的质量：设计质量和符合质量。
►设计质量：是指设计者为一件产品规定的特征。
材料等级、耐久性、及性能的规约都属于设计质量。
如果产品能够依照规约进行制造，则产品的设计质量便会提高。
►符合质量：是指在制造过程中符合设计规格的程度。
同样，符合程度越高，符合质量也就越高。
►在软件开发时，设计质量包括系统的需求、规约和设计。
►符合质量则主要关注实现问题。
如果实现了符合设计、得到的系统满足系统需求和性能目标，则符合质量较高. 对于一个特定的软件而言，我们要首先判断： 什么是质量要素，才能给出提高质量的具体措施; 而不是一股脑地想把所有的质量属性都做好; 否则不仅做不好，还可能得不偿失。
1)正确性◆正确性是指软件按照需求正确执行任务的能力。
“正确性”的语义涵盖了“精确性”。
◆正确性无疑是第一重要的软件质量属性。
◆技术评审和测试的第一关都是检查工作成果的正确性。
◆机器不会主动欺骗人，软件运行出错通常都是人造成的，所以不要找借口埋怨机器有毛病。
2)健壮性◆健壮性是指在异常情况下，软件能够正常运行的能力。
◆正确性描述软件在需求范围之内的行为，而健壮性描述软件在需求范围之外的行为。
◆开发者往往把异常情况错当成正常情况而不作处理，结果降低了健壮性。
◆健壮性有两层含义：一是容错能力，二是恢复能力。
–从语义上理解，恢复不及容错那么健壮。
–Unix容错能力很强，可惜不好用。
–Windows容错能力较差，但是恢复能力很好，而且很好用。
占了90%的操作系统市场。
用户才不管正确性与健壮性的区别，反正软件出了差错都是开发方的错。
所以提高软件的健壮性也是开发者的义务。
3)可靠性 ◆可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。
◆可靠性本来是硬件领域的术语。
比如某个电子设备在刚开始工作时挺好的，但由于器件在工作中其物理性质会发生变化（如发热），慢慢地系统的功能或性能就会失常。
所以一个从设计到生产完全正确的硬件系统，在工作中未必就是可靠的。
◆软件在运行时不会发生物理性质的变化，人们常以为如果软件的某个功能是正确的，那么它一辈子都是正确的。
◆可是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。
◆平时软件运行得好好的，说不准哪一天就不正常了，如有千年等一回的“千年虫”问题，司空见惯的“内存泄露”、“误差累积”问题等等。
◆软件可靠性分析通常采用统计方法，遗憾的是目前可供第一线开发人员使用的成果很少见，大多数文章限于理论研究。
◆口语中的可靠性含义宽泛，几乎囊括了正确性、健壮性。
只要人们发现系统有毛病，便归结为可靠性差。
从专业角度讲，这种说法是确切的。
◆软件可靠性问题主要是在编程时候埋下的祸害（很难测试出来），应当提倡规范化程序设计，预防可靠性祸害。
◆时隐时现的错误一般都属于可靠性问题，纠错的代价很高。
例如当维护人员十万火急地赶到现场时，错误消失了；等维护人员回家后，错误又出现了。
►可靠性的简单度量是“平均失败间隔时间”(MTBF)，其中： ►MTBF=MTTF+MTTR►(MTTF和MTTR分别是“平均失败时间”和 “平均修复时间”的首字母缩写)。
►许多研究人员认为MTBF是一个远比“缺陷 数/KLOC”更为有用的度量指标。
►简而言之，最终用户关心的是失败，而不是总缺陷数。
►由于一个程序中包含的每个缺陷所具有的失败率不同，总缺陷数难以表示系统的可靠性. ►我们必须开发一个“可用性”度量。
►软件可用性是指在某个给定时间点上程序能够按照需求执行的概率。
其定义为： ►可用性=MTTF/(MTTF+MTTR)×100％►MTBF可靠性度量对MTTF和MTTR同样敏感。
►(MTTF和MTTR分别是“平均失败时间”和 “平均修复时间”的首字母缩写)。
►而可用性度量在某种程度上对MTTR较为敏 感，MTTR是软件可维护性的间接度量。
4)性能 ◆性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。
人们总希望软件的运行速度高些，并且占用资源少些。
既要马儿跑得快，又要马儿吃的少。
◆性能优化的关键工作是找出限制性能的“瓶颈”，不要在无关痛痒的地方瞎忙乎。
–程序员可以通过优化数据结构、算法和代码来提高软件的性能。
例如数据库程序的优化。
–算法复杂度分析是很好的方法，可以达到“未卜先知”的功效。
◆性能优化就好像从海绵里挤水一样，你不挤，水就不出来，你越挤海绵越干。
◆有些程序员认为现在的计算机不仅速度越来越高，而且内存越来越大，因此软件性能优化的必要性下降了。
◆这种看法是不对的，殊不知随着机器的升级，软件系统也越来越庞大了和复杂了，性能优化仍然大有必要。
5)易用性◆易用性是指用户使用软件的容易程度。
◆现代人的生活节奏快，干啥事都想图个方便。
所以把易用性作为重要的质量属性对待无可非议。
软件的易用性要让用户来评价。
当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“界面友好”、“方便易用”等词来评价软件产品。
6)清晰性 ◆清晰意味着所有的工作成果易读、易理解，可以提高团队开发效率，降低维护代价。
◆开发人员只有在自己思路清晰的时候才可能写出让别人易读、易理解的程序和文档。
◆可理解的东西通常是简洁的。
一个原始问题可能很复杂，但高水平的人就能够把软件系统设计得很简洁。
7)安全性◆这里安全性是指信息安全，英文是Security而不是Safety。
◆安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。
◆信息安全是一门比较深奥的学问，其发展是建立在正义与邪恶的斗争之上。
◆开发商和客户愿意为提高安全性而投入的资金是有限的，他们要考虑值不值得。
◆究竟什么样的安全性是令人满意的呢？ –一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、风险等因素）高于得到的好处，那么这样的系统可以认为是安全的。
–对于普通软件，并不一点要追求很高的安全性，也不能完全忽视安全性，要先分析黑客行为。
8)可扩展性 ◆可扩展性反映软件适应“变化”的能力。
◆在软件开发过程中，“变化”是司空见惯的事情，如需求、设计的变化，算法的改进，程序的变化等等。
◆由于软件是“软”的，是否它天生就容易修改以适应“变化”？关键要看软件的规模和复杂性。
–如果软件规模很小，问题很简单，那么修改起来的确比较容易，这时就无所谓“可扩展性”了。
要是软件的代码只有100行，那么“软件工程”也就用不着了。
–如果软件规模很大，问题很复杂，倘若软件的可扩展性不好，那么该软件就像用卡片造成的房子，抽出或者塞进去一张卡片都有可能使房子倒塌。
现代软件产品通常采用“增量开发模式”，不断推出新版本，获取增值利润。
可扩展性越来越重要。
可扩展性是系统设计阶段重点考虑的质量属性。
现代软件产品通常采用“增量开发模式”，不断推出新版本，获取增值利润。
可扩展性越来越重要。
可扩展性是系统设计阶段重点考虑的质量属性。
谈到软件的可扩展性，开发人员首先想到的是怎样提高可扩展性，于是努力去设计很好的体系结构来提高可扩展性，却不考虑该不该做这件事。
从商业角度考虑，如果某个软件将不断地推出新版本，那么可扩展性很重要。
但是如果软件永远都不会有下个版本（一次性买卖），那么根本无需提高可扩展性，何必自找苦吃呢！ 9)兼容性 ◆兼容性是指不同产品（或者新老产品）相互交换信息的能力。
例如两个字处理软件的文件格式兼容，那么它们都可以操作对方的文件，这种能力对用户很有好处。
◆兼容性的商业规则：弱者设法与强者兼容，否则无容身之地；强者应当避免被兼容，否则市场将被瓜分。
10)可移植性 ◆软件的可移植性指的是软件不经修改或稍加修改就可以运行于不同软硬件环境（CPU、OS和编译器）的能力，主要体现为代码的可移植性。
–编程语言越低级，用它编写的程序越难移植，反之则越容易。
–这是因为，不同的硬件体系结构（例如IntelCPU和SPARCCPU）使用不同的指令集和字长，而OS和编译器可以屏蔽这种差异，所以高级语言的可移植性更好 –Java程序号称“一次编译，到处运行”，具有100%的可移植性。
–为了提高Java程序的性能，最新的Java标准允许人们使用一些与平台相关的优化技术，这样优化后的Java程序虽然不能“一次编译，到处运行”，仍然能够“一次编程，到处编译”。
◆软件设计时应该将“设备相关程序”与“设备无关程序”分开，将“功能模块”与“用户界面”分开。
8.1.4质量控制 ►“质量控制”是为了保证每件工作产品都满足对它的需求而应用于整个开发周期中的一系列审查、复审和测试。
►质量控制在创建工作产品的过程中包括一个反馈循环。
►度量和反馈相结合，使得能够在得到的工作产品不能满 足其规约时调整开发过程。
►这种方法将质量控制视为整个制造过程的一部分。
►质量控制中的关键概念之一是所有工作产品都具有定义 好的和可度量的规约，可以将每个过程的产品与这一规约进行比较。
反馈循环的引入对于最小化产生的缺陷至关重要。
8.1.5质量保证 ►“质量保证”由管理层的审计和报告功能构成。
►质量保证的目标是为管理层提供有关软件项 目的过程和产品的质量信息所需的数据，从而获得产品质量是否符合预定目标的一定的可见性。
►质量保证包括评审和审核产品及其活动,以验证其是否遵守应用规程和标准.►如果质量保证所提供的数据发现了问题，则管理层负责解决这一问题，并为解决质量问题分配所需的资源。
8.1.6质量的成本 ►质量成本包括所有由质量工作或者进行与质量有关的活动所导致的成本。
►质量成本研究的开展能够为当前质量成本设定基线，标识降低质量成本的机会，并提供一种规范化的比较基础。
►质量成本可以被划分为与预防、鉴定及失败相关的成本。
►“预防成本”包括：
1.·质量计划。
2.·正式技术复审。
3.·测试设备。
4.·培训。
►“鉴定成本”包括为深入了解“首次通过”各个过程时产品的状态而开展的那些活动。
鉴定成本的例子如下：
1.·过程内和过程间审查。
2.·设备校准和维护。
3.·测试。
►“失败成本”是指如果在将产品交付给客户之前已经消除了缺陷时就不会存在的成本。
失败成本可以进一步划分为内部失败成本和外部失败成本。
►“内部失败成本”是指在产品交付之前发现错误而引发的成本。
内部失败成本包括：
1.·返工。
2.·修复。
3.·失败模式分析。
►“外部失败成本”是指与产品交付给客户之后所发 现的缺陷相关的成本。
外部失败成本的例子如下：
1.·解决客户的抱怨。
2.·退换产品。
3.·求助电话支持。
4.·保修工作。
8.2质量运动 全面质量管理(TQM)►第一步是指一个连续的过程改进系统。
目标是开发 一个看的见的、可重复的和可度量的过程。
►第二步将检查影响过程的无形因素，并优化这些因素对过程的影响。
►第三步关注产品的用户,通过检查用户使用产品的方式，而导致产品本身的改进和(潜在地)改进产品的生产过程。
►第四步将管理者的注意力从当前的产品上移开并拓宽。
这是一个面向商业的步骤，通过观察产品在市场上的用途，寻找产品在可以识别的相关领域中的发展机会。
8.2.1SQA活动 ►SQA小组的职责是辅助软件工程小组得到高质量的最终产品. ►软件质量保证的措施§CMM对软件质量保证是这8.3.样2S描QA述活动的：►软件质量保证（QualityAssurance）的目的是为管理者提供有关软件过程和产品的适当的可视性。
►它包括评审和审核软件产品及其活动，以验证其是否遵守既定的规程和标准，并向有关负责人汇报评审和审核的结果。
质量保证（QualityAssurance,QA）是CMM和ISO9001最为推崇的改善软件质量的方法。
简而言之，质量保证活动就是检查软件项目的“工作过程和工作成果”是否符合既定的规范。
过程质量与产品质量存在某种程度的因果关系， 通常“好的过程”产生“好的产品”，而“差的过程”将产生“差的产品”。
假设企业已经制定了软件过程规范，如果质量保证人员发现某些项目的“工作过程以及工作成果”不符合既定的规范，那么马上可以断定产品存在缺陷。
反之，如果质量保证人员没有发现不符合既定规范的东西，那么也可以断定产品是合格的。
符合既定规范的东西并不意味着质量一定合格，仅靠规范无法识别出产品中可能存在的大量缺陷。
◆一般而言,质量保证的技术含量是比较低，只能检查出肤浅的缺陷，不能对付有技术难度的缺陷。
◆所以单独的“质量保证”其实并不能“保证质量”。
◆质量保证对于保证质量而言只是必要的手段，而不是充分的手段。
◆软件质量管理是充满争论的话题。
被人们奉为软件质量管理圣经的CMM和ISO9001似乎并不十分奏效，现实和理想之间的差距太大。
◆经典软件工程教科书以及CMM和ISO9001一般抛开商业目标谈质量管理，本末倒置。
◆世界上还没有万能的软件质量管理圣经，所以要辨证看待CMM和ISO9000. 8.2.2商业目标决定质量目标 ◆重视软件质量是应该的，但是“质量越高越好”并不是普适的真理。
◆只有极少数软件应该追求“零缺陷”，对绝大多数软件而言，商业目标决定了质量目标，而不该把质量目标凌驾于商业目标之上。
◆重要的理念：商业目标决定质量目标。
提高软件质量的最终目的是为了赢利，而不是创造完美无缺的产品。
因此对于普通商业软件而言，并不是“质量越高越好”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。
Ø企业的根本目标是为了获取尽可能多的利润，而不是生产完美无缺的产品。
Ø如果企业销售出去的软件的质量比较差，轻则挨骂，重则被退货甚至被索赔， Ø因此，为了提高用户对产品的满意度，企业必须提高产品的质量。
Ø但是企业不可能为了追求完美的质量而不惜一切代价，当企业为提高质量所付出的代价超过销售收益时，这个产品已经没有商业价值了，还不如不开发。
§企业必须权衡质量、效率和成本，产品质量太低了或者太高了，都不利于企业获取利润。
§企业理想的质量目标不是“零缺陷”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。
8.3软件缺陷的影响 ◆质量的死对头是缺陷（defect,bug…），◆缺陷是混在产品中的人们不喜欢、不想要的东西，它对产品没有好处只有坏处。
◆缺陷越多质量越低，缺陷越少质量越高，提高软件质量的基本手段是消除软件缺陷。
►尽管发现了数以百计的不同类型的错误，但是所有错误都可以追溯到下述原因中的一个或几个：
1.·说明不完整或说明错误(IES)
2.·与客户通信中所产生的误解(MCC)
3.·故意与说明偏离(IDS)
4.·违反编程标准(VPS)
5.·数据表示有错(EDR)
6.·模块接口不一致(IMI)
7.·设计逻辑有错(EDL)
8.·不完整或错误的测试(IET)
9.·不准确或不完整的文档(IID)10.·将设计翻译成程序设计语言中的错误(PLT)11.·不清晰或不一致的人机界面(HCI)12.·杂项(MIS) 消除软件缺陷的三种方式◆提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。
主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。
–在开发软件的时候，即使人们的技术水平很高，并且严格遵守规范，但是人非机器，总是会犯错误的，因此无法完全避免软件中的缺陷。
–当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。
–这种方式效果比较好，人们一般都能学会。
最常用的方法是技术评审、软件测试和过程检查，已经被企业广泛采用并取得了成效。
可在现实之中，大多数软件企业的典型现象是： 在软件交付之前，没有及时消除缺陷。
当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。
质量人员的主要职责：1）负责制定质量计划（很重要但工作量较少）,2）负责过程检查（类似于CMM中的质量保证），约占个人工作量的20%；3）参与技术评审，约占个人工作量的30%；4）参与软件测试，约占个人工作量的30%；5）参与软件过程改进（面向整个机构），约占个人工作量的20%； 8.4制定质量管理计划 质量管理计划就是为了实现质量目标的计划。
而质量目标则是由商业目标决定的。
开发软件产品的最终目的是为了赚钱，所以人们为提高软件质量所付出的代价是有上限的， 项目负责人当然希望代价越低越好。
质量管理计划是全面质量管理的行动纲领。
谁制定质量管理计划？由项目核心成员和质量人员共同协商制定，主要由质量人员起草，由项目经理审批即可。
◆质量管理计划的主要：–
1.质量要素分析–
2.质量目标–
3.人员与职责–
4.过程检查计划–
5.技术评审计划–
6.软件测试计划–
7.缺陷跟踪工具–
8.审批意见 8.5技术评审 8.5.1概念◆技术评审（TechnicalReview,TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。
◆技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。
技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之
一。
◆技术评审的主要好处有： –通过消除工作成果的缺陷而提高产品的质量； –技术评审可以在任何开发阶段执行，不必等到软件可以运行之际，越早消除缺陷就越能降低开发成本； –开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。
◆技术评审有两种基本类型： –正式技术评审（FTR）。
FTR比较严格，需要举行评审会议，参加评审会议的人员比较多。
–非正式技术评审（ITR）。
ITR的形式比较灵活，通常在同伴之间开展，不必举行评审会议，评审人员比较少。
►正式技术复审(FTR)是一种由软件工程师进行的软件质量保证活动。
►FTR的目标是:►
(1)在软件的任何一种表示形式中发现功能、逻辑或 实现的错误；►
(2)证实经过复审的软件的确满足需求；►
(3)保证软件的表示符合预定义的标准；►
(4)得到以一种一致的方式开发的软件；►
(5)使项目更易于管理。
►由于FTR的进行使大量人员对软件系统中原本并不 熟悉的部分更为了解，起到了提高项目连续性和培训后备人员的作用。
►FTR实际上是一类复审方式，包括：►“走查”(Walkthrough)；►“审查”(Inspection)；►“轮查”(Round-robinReview)►以及其他软件小组的技术评估。
►每次FTR都以会议形式进行，只有经过适当 的计划、控制和参与，FTR才能获得成功。
►不论选择何种FTR形式，每个复审会议都应该遵守下面的约束：
1.·复审会议(通常)应该在3到5个人之间进行。
2.·应该进行提前准备，但是每人占用工作时间 应该少于2小时。
3.·复审会议时间应该不超过2小时。
►复审总结报告将回答以下问题：►
1.复审什么？►
2.由谁复审？►
3.发现了什么，结论是什么？ 8.6正式技术评审的流程 8.7技术评审与软件测试 技术评审和软件测试的目的都是为了消除软件的缺陷，两者的主要区别是：
1.前者无需运行软件，评审人员和作者把工作成果摆放在桌面上讨论；
2.而后者一定要运行软件来查找缺陷。
技术评审在软件测试之前执行，尤其是在需求开发和系统设计阶段。
3.相比而言，软件测试的工作量通常比技术评审的大，发现的缺陷也更多。
◆在制定质量计划的时候，已经确定了本项目的主要测试活动、时间和负责人，之后再考虑软件测试的详细计划和测试用例。
◆如果机构没有专职的软件测试人员的话，那么开发人员可以兼职做测试工作。
◆当项目开发到后期，过程检查和技术评审都已经没有多少意义了，开发小组急需有人帮助他们测试软件，如果质量人员参与软件测试，对开发小组而言简直就是“雪中送炭”。
◆强调：质量人员一定要参与软件测试（大约占 其工作量的30％左右），只有这样他才能深入地了解软件的质量 问题，而且给予开发小组强有力地帮助。
8.8过程检查 ◆CMM和ISO9001所述的软件质量保证，实质就是过程检查，即检查软件项目的“工作过程和工作成果”是否符合既定的规范。
◆“过程检查”这个词虽然没有质量保证那么动听，但是其含义直接明了，不会让人误解。
◆为了避免人们误以为“质量保证”能够“保证质量”，最好还是用“过程检查”取代“质量保证”这个术语。
◆过程检查对提高软件质量是有帮助的，只是它的好处没有象质量保证鼓吹的那么好而已。
◆符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果十有八九是质量不合格的。
过程检查的要点是：找出明显不符合规范的工作过程和工作 成果，及时指导开发人员纠正问题，切勿吹毛求疵或者在无关痛痒的地方查来查去。
u不少机构的质量人员并没有真正理解过程检查的意义，老是对照规范，查找错别字、标点符号、排版格式等问题，迷失了方向，这样只有疲劳没有功劳，而且让开发人员很厌烦。
u对于中小型项目而言，过程检查工作由质量人员一个人负责就够了，约占其20％的工作量，让质量人员抽出更多的时间从事技术评审和软件测试工作。
8.9流程◆过程检查计划的要点是确定主要检查项和检查时间（或频度）。
◆质量人员在执行过程检查的时候，如果发现问题，应该立即记录下来。
过程问题也是缺陷，因此最好使用缺陷跟踪工具，有助于提高过程检查的效率。
◆质量人员首先设法在项目内部解决已经发现的质量问题，与项目成员们协商，给出解决措施。
在项目内难以解决的质量问题，由上级领导给出解决措施。
8.10缺陷跟踪工具 ◆如果没有缺陷跟踪工具的话，人们只好用纸张或文件去记录缺陷，不仅变更缺陷信息很麻烦，而且难以共享信息。
◆缺陷跟踪工具就是帮助项目成员记录和跟踪缺陷用的，一般都有数据库支持，可以在局域网内运行。
上有许多缺陷跟踪工具，大家可以免费下载使用。
由于缺陷跟踪工具仅仅是一种辅助性的工具，我们没有必要太在乎该软件的功能，只要用起来方便就行。
目前的缺陷跟踪管理工具，主要有：TestDirector、ClearQuest、Bugzilla、Raid/BMS。
◆缺陷的主要属性：缺陷ID,缺陷类型,缺陷状态,缺陷描述,相 关文件,严重性,优先级,报告者,报告日期,接受者,解决方案（建议）,解决日期。
◆缺陷跟踪工具的常见功能： 查询缺陷,添加缺陷,修改缺陷,删除,缺陷分类图,缺陷趋势图,Email
声明：
该资讯来自于互联网网友发布，如有侵犯您的权益请联系我们。