《全面软件质量管理》核心观点摘录
软件产品的质量定义始终都是满足要求和适合使用，高质量和高等级是有区别的。软件质量目标应该来源于商业目标驱动，商业目标决定了软件的价值。提高软件质量的目标仍然是为了盈利和创造更大的效益，而不是创造完美无缺的产品。
软件产品质量不是靠测试和评审出来的，而是靠设计出来的。关注软件项目中的好质量成本和坏质量成本可以宏观的看到项目软件质量管理的水平。对于软件项目COQ一般在35%-55%，而坏质量成本一般在8-15%，这也说明我们要尽量减少返工，争取第一次就把事情做对。
1.软件的质量属性和质量要素
PMBOK中质量的定义是符合要求和适合使用。CMM对质量的定义是一个系统，组件或过程符合客户或用户的要求或期望的程度。因此可以讲质量更多不是研发者说的，而是用户的最终感受。
通过类比，我们这样理解软件质量：软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们通过改善软件的各种质量属性，从而提高软件的整体质量（否则无从下手）。
软件的质量属性很多，如正确性、精确性，健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等。这些质量属性又可以分为功能性和非功能性两大类。
功能性质量要素:正确性，健壮性，可靠性
非功能性质量因素：性能，易用性，安全性，可扩展性，兼容性，可移植性
a.正确性:第一重要，机器不会欺骗人，软件运行错误都是人为造成的。
b.健壮性:包括容错能力和恢复能力，开发过程中应该充分考虑各种异常和边界。
c.可靠性:可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。
d.性能：性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。(性能问题解决根本还是算法和程序的优化，而不是期待硬件的更高配置)
e.易用性:易用性是指用户使用软件的容易程度。(界面友好仅仅是一方面，还包括人机工程很多内容)
f.安全性:安全性是指防止系统被非法入侵的能力
g.扩展性:反映了软件应对变化的能力
h.兼容性:对硬件的兼容，对软件的兼容
非功能性需求是软件质量重要组成，是架构设计和软件产品化的重要考虑，但往往容易被忽视。特别是在开发通用性的产品的时候，非功能性质量要素必须要考虑全面。
什么是质量要素，应该理解为能够提高用户满意度和提高产品核心竞争力和价值的质量属性。如果某些质量属性并不能产生显著的经济效益，我们可以忽略它们，把精力用在对经济效益贡献最大的质量要素上。简而言之，只有质量要素才值得开发人员下功夫去改善。
2.商业目标决定质量目标
重视软件质量是应该的，但是“质量越高越好”并不是普适的真理。只有极少数软件应该追求“零缺陷”，对绝大多数软件而言，商业目标决定了质量目标，而不该把质量目标凌驾于商业目标之上。
企业的根本目标是为了获取尽可能多的利润，而不是生产完美无缺的产品。如果企业销售出去的软件的质量比较差，轻则挨骂，重则被退货甚至被索赔，因此为了提高用户对产品的满意度，企业必须提高产品的质量。但是企业不可能为了追求完美的质量而不惜一切代价，当企业为提高质量所付出的代价超过销售收益时，这个产品已经没有商业价值了，还不如不开发。
企业必须权衡质量、效率和成本，产品质量太低了或者太高了，都不利于企业获取利润。企业理想的质量目标不是“零缺陷”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。
3.质量保证能够保证质量吗
软件质量保证（Quality Assurance）的目的是为管理者提供有关软件过程和产品的适当的可视性。它包括评审和审核软件产品及其活动，以验证其是否遵守既定的规程和标准，并向有关负责人汇报评审和审核的结果。
简而言之，质量保证活动就是检查软件项目的“工作过程和工作成果”是否符合既定的规范。如此简单的活动为什么被冠以“质量保证”这等份量的术语呢？没有历史典故，经我考究，猜想是源于一个天真的假设：
过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”，而“差的过程”将产生“差的产品”。假设企业已经制定了软件过程规范，如果质量保证人员发现某些项目的“工作过程以及工作成果”不符合既定的规范，那么马上可以断定产品存在缺陷。反之，如果质量保证人员没有发现不符合既定规范的东西，那么也可以断定产品是合格的。
符合既定规范的东西并不意味着质量一定合格，仅靠规范无法识别出产品中可能存在的大量缺陷.
4.全面软件质量管理模型
提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。
其次方法是当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。这种方式效果比较好，人们一般都能学会。最常用的方法是技术评审、软件测试和过程检查，已经被企业广泛采用并取得了成效。
最差的是在软件交付之前，没有及时消除缺陷。当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。可笑的是，当软件系统在用户那里出故障了，那些现场补救成功的人倒成了英雄，好心用户甚至还寄来感谢信。
谁对软件质量负责？是全员负责。任何与软件开发、管理工作相关的人员都对质量产生影响，都要对质量负责。所以人们不要把质量问题全部推出质量人员或测试人员。
谁对软件质量负最大的责任？谁的权利越大，他所负的质量责任就越大。质量人员是成天与质量打交道的人，但他个人并不对产品质量产生最大的影响，所以也不负最大的责任。
质量人员的主要职责：
1.负责制定质量计划（很重要但是工作量比较少）；
2.负责过程检查（类似于CMM中的质量保证），约占个人工作量的20%；
3.参与技术评审，约占个人工作量的30%；
4.参与软件测试，约占个人工作量的30%；
5.参与软件过程改进（面向整个机构），约占个人工作量的20%；
质量管理计划的主要内容（模板见word文件）：
1. 质量要素分析
2. 质量目标
3. 人员与职责
4. 过程检查计划
5. 技术评审计划
6. 软件测试计划
7. 缺陷跟踪工具
8. 审批意见
5.技术评审
技术评审（Technical Review, TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。
技术评审的主要好处有：
1.通过消除工作成果的缺陷而提高产品的质量；
2.技术评审可以在任何开发阶段执行，不必等到软件可以运行之际，越早消除缺陷就越能降低开发成本；
3.开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。
技术评审有两种基本类型：
1.正式技术评审FTR。FTR比较严格，需要举行评审会议多。
2.非正式技术评审ITR。ITR的形式比较灵活，通常在同伴之间开展，不必举行评审会
技术评审和软件测试的目的都是为了消除软件的缺陷，两者的主要区别是：
1.前者无需运行软件，评审人员和作者把工作成果摆放在桌面上讨论；
2.而后者一定要运行软件来查找缺陷。技术评审在软件测试之前执行，尤其是在需求开发和系统设计阶段。
相比而言，软件测试的工作量通常比技术评审的大，发现的缺陷也更多。在制定质量计划的时候，已经确定了本项目的主要测试活动、时间和负责人，之后再考虑软件测试的详细计划和测试用例。
如果机构没有专职的软件测试人员的话，那么开发人员可以兼职做测试工作。当项目开发到后期，过程检查和技术评审都已经没有多少意义了，开发小组急需有人帮助他们测试软件，如果质量人员参与软件测试，对开发小组而言简直就是“雪中送炭”。
强调：质量人员一定要参与软件测试（大约占其工作量的30％左右），只有这样他才能深入地了解软件的质量问题，而且给予开发小组强有力地帮助。
CMM和ISO9001所述的软件质量保证，实质就是过程检查，即检查软件项目的“工作过程和工作成果”是否符合既定的规范。
“过程检查”这个词虽然没有质量保证那么动听，但是其含义直接明了，不会让人误解。为了避免人们误以为“质量保证”能够“保证质量”，我提议用“过程检查”取代质量保证这个术语。
虽然本章批判了“质量保证”的浮夸，但是并没有全盘否定质量保证的好处。过程检查对提高软件质量是有帮助的，只是它的好处没有象质量保证鼓吹的那么好而已。
符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果十有八九是质量不合格的。例如版本控制检查,再例如，机构制定了重要工作成果的文档模板（例如需求规格说明书、设计报告等），要求开发人员写的文档尽可能符合模板。如果质量人员发现开发人员写的文档与机构的模板差异非常大，那么就要搞清楚究竟是模板不合适？还是开发人员偷工减料？
过程检查的要点是：找出明显不符合规范的工作过程和工作成果，及时指导开发人员纠正问题，切勿吹毛求疵或者在无关痛痒的地方查来查去。
不少机构的质量人员并没有真正理解过程检查的意义，老是对照规范，查找错别字、标点符号、排版格式等问题，迷失了方向，这样只有疲劳没有功劳，而且让开发人员很厌烦。
对于中小型项目而言，过程检查工作由质量人员一个人负责就够了，约占其20％的工作量，让质量人员抽出更多的时间从事技术评审和软件测试工作。
本文转自《人月神话的博客》
文章观点摘录自林锐博士《全面软件质量管理》
《全面软件质量管理》核心观点摘录相关推荐
- 软件质量管理之困境与对策思考
相信在不少与软件开发相关的企业内,质量管理部门与软件开发部门在日常运作中形成了如下图所示的"哑铃形"组织结构. 开发部门执行质量管理部门所制定的流程,通过提供证据的形式将各种流程执 ...
- 《人月神话》一句话总结各章核心观点
★[一句话总结各章核心观点] 第1章 焦油坑:提出软件产品现在处于进度和质量焦油坑当中,难以摆脱. 第2章 人月神话:人月估算法是错误的,这会暗示人月可互换,这种方式严重的忽视了一个重要的成本,沟通成 ...
- 如何确保有效的软件质量管理流程
如何确保有效的软件质量管理流程 低质量的软件不仅会导致用户采用率不足,还会危及公司的声誉并增加软件生产成本.不合标准的软件会导致用户留存率低并影响用户参与度,36%的受访者提到更高质量的软件是他们IT ...
- 项目中的软件质量管理
项目中的软件质量管理 本文发表于<软件世界>07年1月杂志,转载请注明. 提起软件质量管理,人们更多地会想起ISO9001.CMM.CMMI这些"质量管理圣经".但国内 ...
- 驭势科技CEO吴甘沙：乘用车智能驾驶淘汰赛的七个核心观点
"自动驾驶下一步该怎么走?我们是有一种焦虑的,尤其2025年可能是非常重要的时间节点,我们从战略层面,如何去面对这么一个淘汰赛?"驭势科技联合创始人.董事长兼CEO吴甘沙在第十四届 ...
- 驭势科技吴甘沙：乘用车智能驾驶淘汰赛的七个核心观点
"自动驾驶下一步该怎么走?我们是有一种焦虑的,尤其2025年可能是非常重要的时间节点,我们从战略层面,如何去面对这么一个淘汰赛?"驭势科技联合创始人.董事长兼CEO吴甘沙在第十四届 ...
- 人月神话---观点摘录
<人月神话> 为什么想看这本书呢? 因为以前的公司虽然名气不大, 但是管理流程都挺规范的 , 没有觉察到管理混乱带来的灾难 , 临时到了一家比较有名气的公司 , 但是在开发过程中, 深深感 ...
- 【软件测试基础理论知识】软件质量、软件质量管理体系、软件质量特性
1.软件质量 质量:质量是一个实体的所有特性,基于这些特性可以满足明显或者隐含的需求,而质量就是实体基于这些特征满足需求的程度. 软件质量的三个层次 1)从用户角度出发,质量即符合需求又能满足需求. ...
- 张逸解构DDD：软件的核心是为用户解决领域相关的问题
软件的核心是其为用户解决领域相关的问题的能力.所有其他特性,不管有多么重要,都要服务于这个基本目的.--EricEvans,<领域驱动设计> 应对软件复杂度,许多顶尖的软件设计人员与开发人 ...
- PB做的史上最强的矢量图监控软件（什么组态软件与监控软件的核心都源于此原理）...
PB做的史上最强的矢量图监控软件(什么组态软件与监控软件的核心都源于此原理)<?xml:namespace prefix = o ns = "urn:schemas-microsoft ...
最新文章
- 6月20日截止，请勿错过热心肠奖学金！
- php 创建文件编码,php fopen创建utf8编码文件例子
- linux中注册系统服务—service命令的原理通俗
- 经典C语言程序100例之五四
- mysql 5.7 双主配置_MySQL5.7.18 双主配置
- 职场的秘密，你知道多少？
- 漫游飞行_除了防打扰，手机飞行模式还有这些作用
- 上次被人说TK不好咯，这次给你整个高大上的
- python中wx_python中wx模块的具体使用方法
- intelliJ idea代码折叠
- php 随机输出字符串,如何使用PHP生成随机字符串
- 织梦木马 data.php,DedeCMS后门木马专杀工具V2.0
- 【1字=16bits的原因，switch汇编详解，跳到中间 jump to middle，guarded-do门卫】
- 最小生成树(Minimum Spanning Tree)
- 软件评测师题库--程序语言基础知识
- uni-app启动时间太长
- 关于使用mathtype插件对word公式进行右编号，章节编号更新，以及红色字体去掉问题
- 神经网络的前向传播与反向传播
- USB PD芯片HUSB361实现15W~65W高效低耗的快充电源设计
- vue 复选框点击获取值