文章目录1 :软件质量管理的基本概念1 .软件的质量属性和质量要素(1)质量属性)2)质量要素2 )商业目标决定质量目标3 )质量保证4 )全面软件质量管理模式5 )技术评审)1)正式和非正式技术评审)2)技术评审会议)3) )5)代码审核二、软件质量特性1、软件质量特性-功能性2、软件质量特性-可靠性3、软件质量特性-易用性4、软件质量特性-效率5、软件质量特性-可维护性6、软件质量特性
一：软件质量管理的基本概念
软件质量是指软件符合用户需求的程度。 具体地说，软件质量是指软件适合明确描述的功能和性能的需要，以及所有专业开发的软件应该具有的隐含特征的程度。
用户需求是衡量软件质量的基础。
除了明确定义的需求外，还满足隐含的需求。
1 .软件质量属性和质量要素(1)质量属性软件质量是许多质量属性的综合体现，每个质量属性都反映了软件质量的各个方面。 人们通过改善软件的各种质量属性来提高软件的整体质量。
软件质量属性多，包括准确性、准确性、稳健性、可靠性、容错性、性能、易用性、安全性、可扩展性、复用性、兼容性、可移植性、可测试性、可维护性和灵活性等。 这些质量特性可以分为功能性和非功能性两类。
)2)质量要素质量要素应理解为能够提高用户满意度、提升产品核心竞争力和价值的质量属性。 如果某些质量属性不能产生显著的经济效益，可以忽略它们，将能源用于对经济效益贡献最大的质量要素。 简而言之，只有质量因素值得开发者下功夫改进。
功能性质量要素：准确性、健壮性和可靠性
非功能性质量因素：性能、易用性、安全性、可扩展性、兼容性和可移植性
答：正确性：第一重要，机器不骗人，软件运行错误都是人为的。
B .健壮性：包括容错和恢复性，在开发中应充分考虑各种异常和边界。
c .可靠性：可靠性是指在一定的环境下，在给定的时间内系统不发生故障的概率。
d .性能：性能通常是指软件的“时间-空间”效率，而不仅仅是软件的运行速度。 (解决性能问题的根本还是算法和程序的优化，而不是期待硬件的更高配置。)
e .易用性：易用性是指用户容易使用软件。 (接口友好不仅是一个方面，还包括人机工程的许多内容) )。
f .安全：安全是指防止系统非法入侵的能力
g .可扩展性：反映了软件适应变化的能力
h .兼容性：硬件兼容性，软件兼容性
非功能需求是软件质量的重要组成部分是体系结构设计和软件产品化的重要考虑但往往被忽视。 特别是在开发通用产品时，非功能性的质量因素必须全面考虑。
2 .商业目标决定质量目标重视软件质量是理所当然的，但“质量越高越好”并不是普遍的真理。 只有极少数软件应该追求“零缺陷”，对大多数软件来说，业务目标决定质量目标，质量目标不应该凌驾于业务目标之上。
企业的根本目标是获得尽可能多的利润，而不是生产完美的产品。 企业销售的软件质量差的话，会被骂轻，重的话会被退货或者投诉。 因此，为了提高用户对产品的满意度，企业必须提高产品质量。 但是企业不能为了追求完美的质量而不惜一切代价。 当企业为提高质量付出的代价超过销售收益时，这个产品已经没有商业价值了，最好不要开发。
企业要权衡质量、效率和成本，产品质量过低或过高，都不利于企业盈利。 企业理想的质量目标不是“零缺陷”，而是正好满足广大用户，将提高质量的成本控制在预算范围内。
3 .质量保证软件质量保证(Quality Assurance )的目的是向管理者提供软件过程和产品的适当可视性。 这包括审查和审查软件产品及其活动，以验证是否遵守既定的规程和标准，并将审查和审查结果报告给相关负责人。
简而言之，质量保证活动就是检查软件项目的“工作过程和工作成果”是否符合既定规范。 这样简单的活动为什么会被冠以“质量保证”这样分量的术语呢？ 因为没有历史根据，所以我调查了一下，推测来自于天真的假设。
过程质量与产品质量存在一定程度的因果关系，通常“好的过程”产生“好的产品”，“坏的过程”产生“坏的产品”。 假设企业已经制定了软件流程规范，如果质量保证人发现某个项目的“工作流程及工作成果”不符合既定规范，可以立即判断产品存在缺陷。 相反，如果质量保证人没有发现不符合规定规范的，也可以判断产品合格。
符合既定规范的并不意味着质量一定合格，光靠规范不能识别产品可能存在的大量缺陷
4 .全面的软件质量管理模式提高软件质量的最佳途径是有效防止开发过程中工作成果出现缺陷，将高质量内置于开发过程中。 主要措施是“不断提高技术水平，不断提高规范化水平”，实际上是练内功，俗称“改进软件流程”。
其次是在工作成果刚出来时及时进行质量检查，及时找出并消除工作成果中的缺陷。 这种方式效果很好，人们可以正常学习。 最常用的方法是技术评审、软件测试、过程检查，已经被企业广泛采用并取得了效果。
最糟糕的是用软件传递
付之前，没有及时消除缺陷。当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。可笑的是，当软件系统在用户那里出故障了，那些现场补救成功的人倒成了英雄，好心用户甚至还寄来感谢信。谁对软件质量负责？是全员负责。任何与软件开发、管理工作相关的人员都对质量产生影响，都要对质量负责。所以人们不要把质量问题全部推出质量人员或测试人员。
谁对软件质量负最大的责任？谁的权利越大，他所负的质量责任就越大。质量人员是成天与质量打交道的人，但他个人并不对产品质量产生最大的影响，所以也不负最大的责任。
技术评审（Technical Review, TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。
技术评审的主要对象：需求和设计规格说明、代码、测试计划、用户手册等。
技术评审分为正式技术评审和非正式技术评审两种基本类型，前者比较严格，需要举行评审会议，参加人员比较多，后者的形式比较灵活，通常在同伴之间开展，不必举行评审会议，参与人员相对较少。
一般来说，对重要性和复杂性较高的工作成果，应进行正式技术评审，对重要性和复杂性相对较低的工作成果，可进行非正式技术评审。
技术评审以会议形式进行，一般有如下约束： 评审会议通常由3~5人参加。 会议之前评审人员要做准备，但每人的准备时间不超过2个小时。
评审会议的时间不超过2个小时。 一次技术评审只关注软件的某一特定部分（例如需求或设计规格说明的一部分）。缩小评审焦点可提高发现错误的可能性。
评审组长把待评审的材料分发给每个评审者，评审者（包括评审组长）审查材料，记下相关的要点，为评审会议做准备。
开评审会议。评审会议由评审组长、评审者、评审对象的开发者参加。其中的一个评审者充当记录员，负责记录会议中发现的所有问题。
由开发小组对提交的评审对象进行讲解。同时评审者可对开发者提问，提出建议和要求，展开讨论。 在讨论中如果发现了问题和错误，由记录员记录下来。
会议结束时必须做出以下三个决策之一： 接受该产品，不需要做修改。 由于错误严重，拒绝接受。等到错误改正后，还要进行另一次评审。
暂时接受该产品，但需要对某一部分进行修改，修改后不需要再进行另一次评审。 决定作出后，所有参加会议的人员签字，确认会议结果。
技术评审会议后，要完成一个“评审总结报告”，其内容包括：评审对象是什么？谁参加了评审？评审的结论是什么？有哪些重要发现？
评审会议上所记录的问题列表通常作为评审总结报告的附件。
跟踪与审核。开发者修改工作成果，消除已发现的缺陷。由指定的审查人员跟踪每个缺陷的状态，直到工作成果合格为止。
评审产品，而不是评审人。评审会议的气氛要轻松和愉快，注意提出问题时的方式和态度，不要让产品开发者产生被审问的感受。
制订评审会议的议程并遵守进度。不要让会议过分拖延。问题的具体解决方案可以在会后讨论。
使用检查清单。为不同的软件产品（需求、设计、代码等）开发检查清单，在检查清单中列出所有重要的、常见的问题，这样可以使评审会议聚焦于一些重要问题。
编码阶段的一种技术评审，由一组人员对程序进行阅读和静态分析，有效地检查程序代码中的缺陷。
评审内容：程序是否符合编码规范，程序结构是否合理，算法和程序逻辑是否正确，程序性能怎样等。 很多程序逻辑错误很难通过测试发现。
适合性:与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性准确性:与能否得到正确或相符的结果或效果有关的软件属性互用性:与同其他指定系统进行交互的能力有关的软件属性
依从性:使软件遵循有关的标准,约定,法规及类似规定的软件属性
安全性:与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性
成熟性:与由软件故障引起失效的频度有关的软件属性
容错性:与在软件故障或违反指定接口的情况下,维持规定的性能水平的能力有关的软件属性
易恢复性:与在失效发生后,重建其性能水平并恢复直接受影响数据的能力以及为达此目的所需的时间和能力有关的软件属性
易理解性:与用户为认识逻辑概念及其应用范围所花的努力有关的软件属性
易学性:与用户为学习软件应用所花的努力有关的软件属性
易操作性:与用户为操作和运行控制所花努力有关的软件属性
时间特性:与软件执行其功能时响应和处理时间以及吞吐量有关的软件属性
资源特性:与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性
易分析性:与为诊断缺陷或失效原因及为判定待修改的部分所需努力有关的软件属性
易改变性:与进行修改,排除错误或适应环境变化所需努力有关的软件属性
稳定性:与修改所造成的未预料结果的风险有关的软件属性易测试性:与确认已修改软件所需的努力有关的软件属性
适应性:与软件无需采用有别于为该软件准备的活动或手段就可能适应不同的规定环境有关的软件属性
易安装性:与在指定环境下安装软件所需努力有关的软件属性
遵循性:使软件遵循与可移植性有关的标准或约定的软件属性
易替换性:与软件在该软件环境中用来替代指定的其他软件的机会和努力有关的软件属性
初期故障率：指软件在初期故障期（一般以软件交付给用户后的三个月内为初期故障期）内单位时间的故障数。
用来评价交付使用的软件的质量，预测什么时候软件运行达到基本稳定。
一般以每100小时的故障数为单位。
偶然故障率：指软件在偶然故障期（一般以软件交付给用户后的4个月以后为偶然故障期）内单位时间的故障数。
它用来度量软件处于稳定状态下的质量。
一般以每1000小时的故障数为单位。
平均失效前时间（Mean Time to Failure，MTTF）：指软件在失效前（两次失效之间）正常工作的平均统计时间。
用来度量软件的可靠性。
平均修复时间（Mean Time to Reparation，MTTR）：指软件失效后，使其恢复正常工作所需要的平均统计时间。
用来度量软件的可维护性。
缺陷密度:指软件单位数量的源代码隐藏的缺陷数量