软件质量评估办法 ()
软件系统质量
记分办法，可以按照月，季或者年进行记分合计，每分对应相应的价格进行奖惩。
上线前
需求覆盖率，至少95%；
问题遗留率，最高5%；
严重BUG比率，最高10%；
试运行过程
初期故障率：指软件在初期故障期（一般以软件交付给用户后的三个月内为初期故障期）内单位时间的故障数。一般以每100小时的故障数为单位。可以用它来评价交付使用的软件质量与预测什么时候软件可靠性基本稳定。初期故障率的大小取决于软件设计水平、检查项目数、软件规模、软件调试彻底与否等因素
偶然故障率：指软件在偶然故障期（一般以软件交付给用户后的四个月以后为偶然故障期）内单位时间的故障数。一般以每1000小时的故障数为单位，它反映了软件处于稳定状态下的质量
运维过程
平均失效间隔时间（MTBF）
指软件在相继两次失效之间正常工作的平均统计时间。在实际使用时，MTBF通常是指当n很大时，系统第n次失效与第n+1次失效之间的平均统计时间。
国外一般民用软件的MTBF大体在1000小时左右。对于可靠性要求高的软件，则要求在1000~10000小时之间。
考核办法：小于1000小时，记10分；
小于500小时，记20分；
小于200小时，记30分；
小于100小时，记50分并记严重缺陷。
易用性指标
易用性可通过多方评审来确定，分优秀、良好、一般、较差、极差；较差，记10分；极差记20分并需进行整改。
性能质量
吞吐率
单位时间软件的信息处理能力（即各种目标的处理批数）。软件必须具有处理海量数据的能力。吞吐率就是体现该能力的参数。随着信息的泛滥，要求软件的吞吐率应该达到数百批
最大并发用户数
系统在用户使用峰值时能够承载的最大用户使用数量，需要通过测试确定，也可由用户指定，通常如果100用户数量，采用80?20原则计算得到每小时峰值活动用户数6.667 /小时
性能每下降5%，记10分，下降超过30%记30分，并需要性能调优。
响应时间
稳定性
平均失效恢复时间
指软件失效后恢复正常工作所需的平均统计时间。对于软件，其失效恢复时间为排除故障或系统重新启动所用的时间，而不是对软件本身进行修改的时间（因软件已经固化在机器内，修改软件势必涉及重新固化问题，而这个过程的时间是无法确定的）。
1小时以内，记1分
2小时以内，记2分
5小时以内，记3分
8小时以内，记5分
超过8小时，记10分，并记为严重故障。
兼容性
系统兼容性
系统能够对多种操作系统进行兼容，例如：WIN，LINUX，UNIX等，各种操作系统的版本也可定义；手机端软件同样适用。
考核办法
每缺少一款要求的兼容系统，记50分；缺少两款以上可拒绝验收。
应用兼容性
对B/S架构软件，对浏览器需进行兼容，例如：IE系列、火狐、CROME、遨游、360等；手机端软件同样适用。
考核办法：每缺少一款要求的兼容浏览器，记20分；缺少三款以上可拒绝验收。
外设兼容性
与各种外设的兼容性，考核办法参见前面内容
版本间数据兼容性
系统升级过程中各版本的数据兼容性，不能出现高版本不兼容低版本数据的情况，考核办法参见前面内容
软件代码质量
代码BUG率
缺陷密度
指软件单位源代码中隐藏的缺陷数量。通常以每千行无注解源代码为一个单位。一般情况下，可以根据同类软件系统的早期版本估计FD的具体值。如果没有早期版本信息，也可以按照通常的统计结果来估计。“典型的统计表明，在开发阶段，平均每千行源代码有50~60个缺陷，交付后平均每千行源代码有15~18个缺陷”。
代码编写质量
代码规范符合度
代码编写内容是否按照代码编写规范进行编写，每出现一处不符合规范的内容，记1分，代码编写内容满足规范少于30%，记100分并需要整改。
代码注释量
理想情况为1:1,1:5，记10分；1:10，记20分
开发过程质量
开发过程符合度
开发过程是否按照工期和流程进行。
人员考核
开发工程师
测试工程师
运维工程师
软件评价指标
软件评价指标 Last updated at 10:00 am on 25th December 2020
我们常说某某软件好用，某软件功能全、结构合理、层次分明。这些表述很含糊，用来评价软件质量不够确切，不能作为企业选购软件的依据。对于企业来说，开发单位按照企业的需求，开发一个应用软件系统，按期完成并移交使用，系统正确执行用户规定的功能，仅仅满足这些是远远不够的。因为企业在引进一套软件过程中，常常会出现如下问题： ● 定制的软件可能难于理解，难于修改，在维护期间，企业的维护费用大幅度增加； ● 企业对外购的软件质量存在怀疑，企业评价软件质量没有一个恰当的指标，对软件可靠性和功能性指标了解不足； ● 软件开发商缺乏历史数据作为指南，所有关于进度和成本的估算都是粗略的。因为没有切实的生产率指标，没有过去关于软件开发过程的数据，企业无法精确评价开发商的工作质量。 为此，有必要先了解软件的质量评价体系。美国的.Ｂoehm和先后提出了三层次的评价度量模型：软件质量要素、准则、度量。随后提出了自己的软件质量度量SQM技术，波音公司在软件开发过程中采用了SQM技术，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在成本控制和进度安排方面取得了良好的效果。 第一层是软件质量要素，软件质量可分解成六个要素，这六个要素是软件的基本特征：
1. 功能性：软件所实现的功能满足用户需求的程度．功能性反映了所开发的软件满足用户称述的或蕴涵的需求的程度，即用户要求的功能是否全部实现了。 2. 可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度。可靠性对某些软件是重要的质量要求，它除了反映软件满足用户需求正常运行的程度，且反映了在故障发生时能继续运行的程度。 3. 易使用性：对于一个软件，用户学习、操作、准备输入和理解输出时，所做努力的程度。易使用性反映了与用户的友善性，即用户在使用本软件时是否方便。 4. 效率：在指定的条件下，用软件实现某种功能所需的计算机资源（包括时间）的有效程度。效率反映了在完成功能要求时，有没有浪费资源，此外＂资源"这个术语有比较广泛的含义，它包括了内存、外存的使用，通道能力及处理时间。 5. 可维修性：在一个可运行软件中，为了满足用户需求、环境改变或软件错误发生时，进行相应修改所做的努力程度。可维修性反映了在用户需求改变或软件环境发生变更时，对软件系统进行相应修改的容易程度。一个易于维护的软件系统也是一个易理解、易测试和易修改的软件，以便纠正或增加新的功能，或允许在不同软件环境上进行操作。 6. 可移植性：从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度。 第二层是评价准则，可分成22点。包括精确性（在计算和输出时所需精度的软件属性）；健壮性（在发生意外时，能继续执行和恢复系统的软件属性）；安全性（防止软件受到意外或蓄意的存取、使用、修改、毁坏或泄密的软件属性）；以及通信有效
软件质量评估办法
软件系统质量 记分办法，可以按照月，季或者年进行记分合计，每分对应相应的价格进行奖惩。 上线前 ；95%需求覆盖率，至少 ；5%问题遗留率，最高 BUG严重；10%比率，最高 试运行过程 内（一般以软件交付给用户后的三个月内为初期故障期）指软件在初期故障期初期故障率： 可以用它来评价交付使用的软件质小时的故障数为单位。100一般以每单位时间的故障数。 量与预测什么时候软件可靠性基本稳定。检查项目初期故障率的大小取决于软件设计水平、 数、软件规模、软件调试彻底与否等因素 偶然故障率：指软件在偶然故障期（一般以软件交付给用户后的四个月以后为偶然故障期） 小时的故障数为单位，它反映了软件处于稳定状态下1000内单位时间的故障数。一般以每 的质量 运维过程 ）MTBF平均失效间隔时间（
通MTBF指软件在相继两次失效之间正常工作的平均统计时间。在实际使用时， 次失效之间的平均统计时间。n+1次失效与第n很大时，系统第n常是指当 小时左右。1000大体在MTBF国外一般民用软件的则对于可靠性要求高的软件， 小时之间。1000~10000要求在 分；10小时，记1000考核办法：小于 分；20小时，记500小于 分；30小时，记200小于 分并记严重缺陷。50小时，记100小于 易用性指标 分；极差10易用性可通过多方评审来确定，分优秀、良好、一般、较差、极差；较差，记 分并需进行整改。20记 性能质量 吞吐率 。软件必须具有处理海量数据的能单位时间软件的信息处理能力（即各种目标的处理批数） 力。吞吐率就是体现该能力的参数。随着信息的泛滥，要求软件的吞吐率应该达到数百批 最大并发用户数 也可由用户指定，需要通过测试确定，系统在用户使
浅析软件质量指标度量
软件质量指标度量 V 1.0 2012.3
目录 1综述 (3) 1.1编写目的 (3) 1.2阅读指南 (3) 2软件质量指标 (4) 2.1需求功能点覆盖率 (4) 2.2用例执行覆盖率 (4) 2.3缺陷修复率（截至于**年*月*日） (5) 2.4缺陷遗留个数（截至于**年*月*日） (5) 2.5缺陷分布统计（模块缺陷率） (5) 2.6缺陷分布统计（严重缺陷率） (6) 2.7缺陷密度及收敛 (7) 3测试过程质量指标 (9) 3.1缺陷探测率 (9) 3.2有效缺陷率 (9) 3.1用例执行效率 (10) 3.2缺陷发现率 (10) 4交付质量指标 (12) 4.1加载回退率 (12) 4.2故障回退率 (12) 5版本说明 (13)
1综述 1.1 编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。 1.2 阅读指南 ●软件测试质量指标主要针对研发项目、商务项目被测产品出具数据 度量。 ●测试过程质量指标主要为测试经理、测试组长对测试人员的测试执 行质量出具数据度量。 ●交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用，也可结合使用。
2软件质量指标 2.1 需求功能点覆盖率 【需求覆盖率】：计算测试用例总数之和除以与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。 【公式】：∑测试用例数（个）/ ∑功能点（个） 说明：用例覆盖需求矩阵，一个需求对应多个功能点。 【数据来源】：《联通集中集团客户业务支撑系统销售管理用户需求说明书》《联通集中集团客户业务支撑系统销售管理需求跟踪矩阵》 【计算结果】需求覆盖率=113/8=14.13 2.2 用例执行覆盖率 【用例执行覆盖率】：计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。 【公式】：∑执行的测试用例个数（个）/ ∑测试用例个数（个）*100% 【数据来源】：《iSMS测试进度跟踪表》 【计算结果】：用例执行覆盖率=100%
软件质量评估与控制
软件质量评估与控制 朱向荣1罗桂林2 摘要：随着信息技术的发展，软件产品的应用范围越来越广泛，如何开发高质量的软件产品成为热点的研究内容。而软件质量的评估和控制是软件质量管理的重要方面。本文在学习他人研究成果的基础上对如何进行软件质量控制和评估进行总结，以形成对主流软件质量评估和控制方法的初步认识。 1 引言 随着信息时代的发展，计算机软件的需求愈来愈复杂，规模愈来愈大。软件企业随着自身规模的不断扩大，所从事的软件工程项目的工作量和复杂度也不断升级。这些都导致软件企业在软件开发、服务提供和工程实施过程中所遇到的问题越来越多，软件质量要得到保障越来越具有挑战性。软件质量问题，已经成为国家政府、工业界、学术界以及社会各界关注的重要问题。一些专家认为，21世纪计算机软件发展的大方向将是质量的提高优先于性能和功能的改进，超高质量软件的开发技术将是打开21世纪高技术市场的钥匙。因此，研究和应用软件质量控制技术是一项迫切而且重要的任务。 软件质量控制和软件质量评估是软件工程中非常重要的研究领域，有大量的专家学者和软件开发人员从事这方面的研究，国际上也出台了有一系列的标准对软件质量的各个方面进行规范，各种进行软件质量度量的方法也不断被提出。但是由于软件本身的复杂性和软件技术发展迅速等原因，到目前为止，软件质量控制和评估在理论上和技术上都很不成熟，如何系统的、客观的控制软件产品质量是几十年来一直困扰着人们的难题。 2 软件质量概述 2.1软件质量定义 不同的组织对软件质量与不同的定义。 国际标准化组织ISO在质量特性国际标准ISO／IEC9126中将软件质量定义为反映软件产品满足规定需求和潜在需求能力的特征和特性的总和。 MJ．Fisher将软件质量定义为：所有描述计算机优秀程度的特性的组合。也就是说为了满足软件的各项精确定义的功能、性能要求，符合文档化的开发标准，需要相应的给出或设计一些质量特性及其组合，要得到高质量的软件产品，就必须使这些质量特性满足。 按照ANSI／IEEE Std 1061．1992中的标准，软件质量定义为：与软件产品1.朱向荣：学号ZY1106151，北京航空航天大学计算机学院ZY班
软件开发度量及考核方法精修订
软件开发度量及考核方 法 集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
本人觉得如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。虽然目前很多公司有这方面的绩效考核，但是大多数没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。以下文档是本人根据以前经验和相关的资料所编写的度量方法和考核方法，希望能对公司改善考核制度有用。由于时间有限，有不足之处，请各位仁兄多提意见，谢谢！ 1 目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 2 软件项包括 1）技术文档：参照公司"软件工程产品集"，所确定的配置项；主要包括：可行性分析报告、需求分析报告、软件功能规格说明、开发计划、质量计划、系统设计报告、测试文档、技术报告、用户手册、总结报告等； 2）计算机程序。 3 度量数据的来源 1）项目计划； 2）评审报告； 3）测试报告； 4）问题报告； 5）软件维护记录； 4 质量度量 度量指标 主要根据各类软件项检查表的检查指标来确定，例如，软件需求规格说明书检查表（见附录1），有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。 质量等级 1）软件项的质量等级的确定根据度量综合指标进行。 2）度量综合指标计算公式为：Total = ∑QiMi。 3）其中i=1,2,...n代表指标数量； 4）Q代表度量的指标； 5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。 度量指标权重系数表： 序号指标权重 1 指标1 权数1 2 指标2 权数2 3 指标3 权数3 4 指标4 权数4 5 指标5 权数5 加权平均分 6）质量评价：一般地，根据度量综合指标值，有以下评分标准。 质量评价计分标准表 序号得分质量评价 1 ～优质
软件验收测试标准28719
软件质量与测试效果评估标准 1编写目的 本文档是对独立测试效果及软件质量从缺陷方面进行考核的依据，该标准仅作为整体考核标准中的一个组成部分即：缺陷考核部分。 2适用范围 本标准适用于软件质量与软件测试质量的考核。 3 评价基准 软件质量考核基准：以最后测试组递交的测试总结报告中所提交的有效缺陷为考核指标。测试质量考核基准：以软件试运行阶段用户发现的有效缺陷和非测试人员发现的有效缺陷为考核指标。 有效缺陷：经过评审确定为影响软件质量或发布的缺陷（包括：确定修改、暂缓修改的）建议性的 4 验收测试进入准则 1) 软件产品通过单元测试、集成测试和系统测试。 2) 测试组提交以下测试工件：测试计划、测试任务书、测试用例、测试报告、测试分析总结。5软件验收测试工作程序 测试完成后按项目管理规定，成立测试（项目）验收小组，启动测试验收总结会 5.1根据测试任务书进行测试质量前期评审。 5.2根据测试总结报告进行软件质量评审。（测试角度） 6 软件验收测试合格通过准则 1 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求 2 所有测试项没有残余一级、二级错误 3 立项审批表、需求分析文档、设计文档和编码实现一致 4 验收测试工件齐全（见验收测试进入准则）
5软件测试合格须符合以下标准。 1）软件产品未经测试合格，不能上线，如需要强制上限，责任应有项目负责人承担。 6 测试质量合格须符合以下标准 1）以上为用户或非测试人员发现的有效缺陷，且改缺陷不是由需求、功能的变更引起的且在测试任务书规定的测试内容范围内的缺陷。 2) 1级BUG、2级BUG为独立条件，3级BUG、4级BUG为组合条件 3）用户或非测试人员发现的有效缺陷的总数不得大于一定的比例：(10%) 用户或非测试人员发现的有效缺陷的总数/测试总结报告提交有效缺陷总数×100% 举例：满足以下任何一条即视为测试质量不合格 用户或非测试人员发现的有效1级BUG>2 用户或非测试人员发现的有效2级BUG>4 用户或非测试人员发现的有效缺陷的总数与测试发现的有效缺陷总数的比例>10% 用户或非测试人员发现的有效3级BUG>5
软件项目量化管理方法
软件项目量化管理方法 摘要：本文在对软件企业量化管理应用常见问题分析的基础上，以解决可操作性、可比性等问题为着眼点，识别出了量化管理中必须明确的四要素，表述了企业在量化四要素上采用的常见做法。 本文采用80/20原则，说明了企业在识别度量对象时应避免的问题；采用持续改进的理论，说明了企业在量化管理应遵循的客观规律。在结合平衡记分卡与目标驱动组合式的量化管理方法理论基础上，提出了软件企业的量化管理的具体应用步骤。 关键词：量化管理四要素80/20原则持续改进GQ(I)M 1. 引言 如今，很多国内软件企业选择采用能力成熟度系列模型（Capa bility Maturity Model, CMM）或其它模型来建立本企业的软件过程规范，欲通过提升软件过程的能力达到提高产品质量、降低开发风险、减少开发成本、保证产品按时交付等目的。将软件过程规范的一个目的就是使软件过程可视化，这个可视化则要求了对软件过程的量化；而产品质量是否提高、开发风险是否降低、开发成本是否减少、项目延期是否缩短，对这些问题的回答则要求了对软件项目的量化；软件过程改进与量化管理息息相关。
不少企业在将识别出的量化管理方法应用于软件项目管理过程时，发现不少问题。最为常见的是： 量化工作的可操作性不强，如：部分量化数据难以收集、难以统计投入的成本没有得到预期的产出。如：量化工作投入了成本，但形成的量化结果参考价值不高提供给管理层用于决策的支持数据也不够，数据缺乏可比性量化结果不是管理层所关心的，达不到管理层预期的过程可视化程度 针对此类问题，本文识别出了在量化管理中必须要考虑的四个方面，即：量化四要素，并从量化四要素对量化管理方法进行了分析，建议了软件企业采用的量化管理方法。 2. 量化四要素 “只有通过对产品、过程的度量，才能描述、评价、提高产品与过程”。 笔者认为，要度量，就要明确度量的对象；要度量对象，就要明确标识度量对象的计量单位；要产生度量结果，就要明确度量方法，包括度量技术和数据收集的方法；要评价度量对象，就要明确用于比对的基准指标，即表征度量对象目前情况的标尺，通过该标尺与度量结果的比对，得出对度量对象的评价。而度量对象（Object）、计量单位（Unit）、度量方法（Method）、基准指标（Benchmark），这就是笔者所说的量化四要素。
5个常用的软件质量指标
5 个常用的软件质量指标 在软件开发中，软件质量是衡量软件是否符合需求、标准的重要体现。除了代码质量外，影响软件整体质量的因素还有很多。因此，要确保软件的整体质量，就需要在各个环节严格控制。 本文列出了衡量软件质量的5个最常用的指标。 1、SLOC（Source Lines of Code，源代码行） 计算代码行数可能是最简单的衡量指标，主要体现了软件的规模，并为项目增长和规划提供了相关数据。例如，如果每月统计一次代码的行数，就可以绘制一个项目发展概览图。当然，由于存在项目重构或是设计阶段等因素，这种方式并不太可靠，但是可以为项目的发展提供一个视角。 可以只统计逻辑代码行（Source Logical Line of Code，SLLOC），这样可以获得稍准确的信息。逻辑代码行不包含空行、单个括号行和注释行。可以使用Metrics 工具来统计。 代码行数不应该用来评估开发者的效率，否则，可能会产生重复、不可维护的或不专业的代码。 2、每个代码段/模块/时间段中的bug数 要想实现更好的测试以及更高的可维护性，bug 跟踪是必不可少的。每个代码段、模块或时间段（天、周、月等）内的 bug 可以很容易通过工具统计出来（如 Mantis）。这样，可以及早发现并及时修复。 Bug 数可以作为评估开发者效率的指标之一，但必须注意，如果过分强调这种评估方法，软件开发者和测试者可能会成为敌人。在生产企业中，要保证员工彼此之间的凝聚力。 为了更好的实现评估，可以根据重要性和解决成本将 bug 划分为低、中、高三个级别。 3、代码覆盖率 在单元测试阶段，代码覆盖率常常被拿来作为衡量测试好坏的指标，也用来考核测试任务完成情况。可以使用的工具也有很多，如 Cobertura 等。 代码覆盖率并不能代表单元测试的整体质量，但可以提供一些测试覆盖率相关的信息，可以和其他一些测试指标一起来使用。 此外，在查看代码覆盖率时，还需注意单元测试代码、集成测试场景和结果等。
软件质量与测试效果评估标准之缺陷考核
软件质量与测试效果评估标准之缺陷考核 1、编写目的 本文档是对独立测试效果及软件质量从缺陷方面进行考核的依据，该标准仅作为整体考核标准中的一个组成部分即：缺陷考核部分。 2、适用范围 本标准适用于软件质量与软件测试质量的考核。 3、评价基准 软件质量考核基准：以最后测试组递交的测试总结报告中所提交的有效缺陷为考核指标。 测试质量考核基准：以软件试运行阶段用户发现的有效缺陷和非测试人员发现的有效缺陷为考核指标。 有效缺陷：经过评审确定为影响软件质量或发布的缺陷（包括：确定修改、暂缓修改的）建议性的E类缺陷不算有效缺陷。 4、验收测试进入准则 1）软件产品通过单元测试、集成测试和系统测试。 2）测试组提交以下测试工件：测试计划、测试任务书、测试用例、测试报告、测试分析总结。 5、软件验收测试工作程序 测试完成后按项目管理规定，成立测试（项目）验收小组，启动测试验收总结会。 5.1 根据测试任务书进行测试质量前期评审。 5.2 根据测试总结报告进行软件质量评审。（测试角度） 6、软件验收测试合格通过准则 1）软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求 2）所有测试项没有残余一级、二级错误 3）立项审批表、需求分析文档、设计文档和编码实现一致 4）验收测试工件齐全（见验收测试进入准则）
5）软件测试合格须符合以下标准。 ● 以上比例为错误占总测试模块（不包括E类）的比例。 ● 软件产品未经测试合格，不允许投运。 6）测试质量合格须符合以下标准 ● 以上为用户或非测试人员发现的有效缺陷，且改缺陷不是由需求、功能的变更引起的且在测试任务书规定的测试内容范围内的缺陷。 ● A类错误、B类错误为独立条件，C类错误、D类错误为组合条件 ● 用户或非测试人员发现的有效缺陷的总数不得大于一定的比例：（10%） 用户或非测试人员发现的有效缺陷的总数/测试总结报告提交有效缺陷总数×100% 举例：满足以下任何一条即视为测试质量不合格 用户或非测试人员发现的有效A类错误>2 用户或非测试人员发现的有效A类错误>4 用户或非测试人员发现的有效缺陷的总数与测试发现的有效缺陷总数的比例>10% 用户或非测试人员发现的有效C类错误、D类错误均>5
电子装备软件质量评估模型分析
总第２４３期 ２０１０年第１期 计算机与数字工程 Ｃｏｍｐｕｔｅｒ＆ＤｉｇｉｔａｌＥｎｇｉｎｅｅｒｉｎｇ Ｖ０１．３８Ｎｏ．１ ４４ 电子装备软件质量评估模型分析＋ 崔天意刘庆峰张芝龙 （９１４０４部队秦皇岛０６６００１） 摘要软件质量是软件的生命，软件测试和评价是保证软件质量的重要手段。没有完备的软件质量评价程序和评价方法，质量是很难保证的。文章提出了一种基于缺陷分布模型、专家知识和神经网络方法的电子装备软件专用的质量评估方法，该方法使用电子装备软件的可靠性评估值、功能分析评估值和作战效能评估指标等专用参数作为模型的输入，利用加权综合评判方法完善模型，最终输出软件质量评估值。经实装测试试验证明了该方法的可行性和有效性。 关键词电子装备软件；神经网络；作战效能；质量评估 中图分类号ＴＰ２７３＋．４ ＥｌｅｃｔｒｏｎＷｅａｐｏｎｒｙＳｏｆｔｗａｒｅＱｕａｌｉｔｙＥｖａｌｕａｔｉｏｎＭｅｔｈｏｄ ＣｕｉＴｉａｎｙｉＬｉｕＱｉｎｇｆｅｎｇＺｈａｎｇＺｈｉｌｏｎｇ （Ｎｏ９１４０４ＴｒｏｏｐｓｏｆＰＬＡ，Ｑｉｎｈｕａｎｇｄａｏ０６６００１） ＡｂｓｔｒａｃｔＴｈｅｓｏｆｔｗａｒｅｑｕａｌｉｔｙｉｓｔｈｅｉｍｐｏｒｔａｎｃｅｏｆｔｈｅｓｏｆｔｗａｒｅ，ｓｏｆｔｗａｒｅｔｅｓｔａｎｄｅｖａｌｕａｔｉｏｎａｒｅｔｈｅｉｍｐｏｒｔａｎｔｍｅａｎｓｗｈｉｃｈｐｒｏｍｉｓｅｓｓｏｆｔｗａｒｅｑｕａｌｉｔＢＴｈｅｒｅａｒｅｎｏｃｏｍｐｌｅｔｅｅｖａｌｕａｔｉｏｎｐｒｏｃｅｄｕｒｅｏｆｔｈｅｓｏｆｔｗａｒｅｑｕａｌｉｔｙａｎｄｅｖａｌｕａｔｉｏｎｍｅｔｈｏｄ，ｔｈｅｑｕａｌｉｔｙｉｓｖｅｒｙｄｉｆｆｉｃｕｌｔａｓｓｕｒｉｎｇ．ＴｈｅａｒｔｉｃｌｅｐｕｔｆｏｒｗａｒｄａｋｉｎｄｏｆｔｈｅｓｏｆｔｗａｒｅｑｕａｌｉｔｙｖａｌｕａｔｉｏｎｍｅｔｈｏｄｆｏｒｔｈｅｅｌｅｃｔｒｏｎｂａｔｔｌｅｓｙｓｔｅｍａｃｃｏｒｄｉｎｇｔＯｂｕｇｄｉｓｔｒｉｂｕｔｉｎｇｅｘｐｅｒｆｓｋｎｏｗｌｅｄｇｅａｎｄｎｅｒｖｅｎｅｔｗｏｒｋＴｈｅｍｅｔｈｏｄｕｓａｇｅｅｌｅｃｔｒｏｎｗｅａｐｏｎｒｙｓｏｆｔ—ｗａｒｅｂａｔｔｌｅｅｆｆｅｃｔｅｔｃｐａｒａｍｅｔｅｒｂｅｔｈｅｉｍｐｏｒｔａｔｉｏｎｏｆｍｏｄｅｌ．ｔｈｅｅｘｐｌｏｉｔａｔｉｏｎａｄｄｓｐｏｗｅｒｃｏｍｐｒｅｈｅｎｓｉｖｅａｄｊｕｄｉｃａｔｅａｍｅｔｈｏｄｅｓｔａｂｌｉｓｈｍｅｎｔｍｏｄｅｌ．Ｏｕｔｐｕｔｓｏｆｔｗａｒｅｑｕａｌｉｔｙｖａｌｕａｔｉｏｎ．ＴｈｒｏｕｇｈａｃｔｕａｌｌｙｐａｃｋｅｄａｔｅｓｔｔＯｅｘｐｅｒｉｍｅｎｔｔＯｐｒｏｖｅｔｈｅｐｏｓｓｉｂｉｌｉ—ｔｙ ａｎｄｕｓｅｆｕｌｎｅｓｓｏｆｔｈａｔｍｅｔｈｏｄ． Ｋｅｙ Ｗｏｒｄｓｅｌｅｃｔｒｏｎｗｅａｐｏｎｒｙｓｏｆｔｗａｒｅ，ｎｅｔｗｏｒｋｎｅｕｒｏｎ，ｃａｍｐａｉｇｎｅｆｆｉｃｉｅｎｃｙ，ｑｕａｌｉｔｙｅｖａｌｕａｔｉｏｎＣｌａｓｓＮｕｍｂｅｒＴＰ２７３＋．４ １引言 在现代各种电子战装备系统中，以软件为核心的产品得到了广泛的应用，随着系统中软件成分的不断增加，使得系统对于软件的依赖程度越来越大，对软件质量尤其是可靠性、可维护性和功能性的要求也越来越高［１］。软件质量是软件的生命，软件测试和评价是保证软件质量的重要手段。没有完备的软件质量评价程序和评价方法，质量是很难保证的。 现役电子战装备软件在通过测试之后，各项技术指标可以达到预定要求，但不一定具有较高的作战效能。即软件技术测试合格的系统仍然不符合实际应用要求。因为软件测试只注重软件本身的故障特性，而忽略了对于装备软件至关重要的软硬件配置拟合度和战术合理性等非技术性指标。例如：软件设计的舰艇机动动作要求舰艇在短时间内转向；多种干扰样式组合导致干扰失败；电磁干扰使软件失效。因此作战效能评估对电子战装备软件质量起决定性作用。 从常规的角度来看，质量是一个无形的特性，可以对其进行讨论、感知和判断，不能进行测量。从专业的角度来看，为了提高质量，必须对其进行定义和测量，并将其描述为“与客户需求的一致 －收稿日期：２００９年９月１０日，修回日期：２００９年１０月１５日 作者简介：崔天意，男，硕士，工程师，研究方向：作战系统软件测试及软件测试质量研究。万方数据
如何对软件质量进行评估
如何对软件质量进行评估 1 软件质量的有关概念软件质量是“软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和”。根据软件质量国家标准GB-T8566--2001G，软件质量评估通常从对软件质量框架的分析开始。1.1 软件质量框架模型如图1所示，软件质量框架是一个“质量特征—质量子特征—度量因子”的三层结构模型。 在这个框架模型中，上层是面向治理的质量特征，每一个质量特征是用以描述和评价软件质量的一组属性，代表软件质量的一个方面。软件质量不仅从该软件外部表现出来的特征来确定，而且必须从其内部所具有的特征来确定。 第二层的质量子特征是上层质量特征的细化，一个特定的子特征可以对应若干个质量特征。软件质量子特征是治理人员和技术人员关于软件质量问题的通讯渠道。 最下面一层是软件质量度量因子（包括各种参数），用来度量质量特征。定量化的度量因子可以直接测量或统计得到，为最终得到软件质量子特征值和特征值提供依据。如何对软件质量进行评估（图一） 图1 软件质量框架模型1.2 软件质量特征 按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价： a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。 b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。 c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属
性。 d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。 e.可维护特征：与进行指定的修改所需的努力有关的一组属性。 f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。 其中每一个质量特征都分别与若干子特征相对应。 2 评估指标的选取原则 选择合适的指标体系并使其量化是软件测试与评估的要害。评估指标可以分为定性指标和定量指标两种。理论上讲，为了能够科学客观地反映软件的质量特征，应该尽量选择定量指标。但是对于大多数软件来说，并不是所有的质量特征都可以用定量指标进行描述，所以不可避免地要采用一定的定性指标。 在选取评估指标时，应该把握如下原则： a.针对性 即不同于一般软件系统，能够反映评估软件的本质特征，具体表现就是功能性与高可靠性。 b.可测性 即能够定量表示，可以通过数学计算、平台测试、经验统计等方法得到具体数据。 c.简明性 即易于被各方理解和接受。 d.完备性 即选择的指标应覆盖分析目标所涉及的范围。 e.客观性 即客观反映软件本质特征，不能因人而异。 应该注重的是，选择的评估指标不是越多越好，要害在于指标在评估中所起的作用的大小。假如评估时指标太多，不仅增加结果的复杂性，有时甚至会影响评估的客观性。指标的确定一般是采用自顶向下的方法，逐层分解，并且需要在动态过程中反复综合平衡。 3 软件质量评估指标体系
软件质量度量指标v1.0
软件质量指标度量 1综述 (2) 1.1编写目的 (2) 1.2阅读指南 (2) 2软件质量指标 (3) 2.1需求功能点覆盖率 (3) 2.2用例执行覆盖率 (3) 2.3缺陷修复率（截至于**年*月*日） (4) 2.4缺陷遗留个数（截至于**年*月*日） (4) 2.5缺陷分布统计（模块缺陷率） (4) 2.6缺陷分布统计（严重缺陷率） (5) 2.7缺陷密度及收敛 (5) 3测试过程质量指标 (8) 3.1缺陷探测率 (8) 3.2有效缺陷率 (8) 3.1用例执行效率 (9) 3.2缺陷发现率 (9) 4交付质量指标 (11) 4.1加载回退率 (11) 4.2故障回退率 (11) 5版本说明 (12)
1综述 1.1编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。 1.2阅读指南 ●软件测试质量指标主要针对研发项目、商务项目被测产品出具数据 度量。 ●测试过程质量指标主要为测试经理、测试组长对测试人员的测试执 行质量出具数据度量。 ●交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用，也可结合使用。
2软件质量指标 2.1需求功能点覆盖率 【需求覆盖率】：计算测试用例总数之和除以与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。 【公式】：∑测试用例数（个） / ∑功能点（个） 说明：用例覆盖需求矩阵，一个需求对应多个功能点。 【数据来源】：《联通集中集团客户业务支撑系统销售管理用户需求说明书》《联通集中集团客户业务支撑系统销售管理需求跟踪矩阵》 【计算结果】需求覆盖率=113/8=14.13 2.2用例执行覆盖率 【用例执行覆盖率】：计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。 【公式】：∑执行的测试用例个数（个） / ∑测试用例个数（个）*100% 【数据来源】：《iSMS测试进度跟踪表》 【计算结果】：用例执行覆盖率=100%
软件质量评估概念
软件质量评估 1 软件质量的有关概念 软件质量是“软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和”。根据软件质量国家标准GB-T8566--2001G，软件质量评估通常从对软件质量框架的分析开始。 1.1 软件质量框架模型 如图1所示，软件质量框架是一个“质量特征—质量子特征—度量因子”的三层结构模型。 在这个框架模型中，上层是面向管理的质量特征，每一个质量特征是用以描述和评价软件质量的一组属性，代表软件质量的一个方面。软件质量不仅从该软件外部表现出来的特征来确定，而且必须从其内部所具有的特征来确定。 第二层的质量子特征是上层质量特征的细化，一个特定的子特征可以对应若干个质量特征。软件质量子特征是管理人员和技术人员关于软件质量问题的通讯渠道。 最下面一层是软件质量度量因子（包括各种参数），用来度量质量特征。定量化的度量因子可以直接测量或统计得到，为最终得到软件质量子特征值和特征值提供依据。 1.2 软件质量特征 按照软件质量国家标准GB-T8566--2001G，软件质量可以用下列特征来评价： a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。 b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。 c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。 d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。 e.可维护特征：与进行指定的修改所需的努力有关的一组属性。 f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。 其中每一个质量特征都分别与若干子特征相对应。
软件质量度量指标v
软件质量度量指标V ?
作者:日期:
4.1 加载回退率 错误!未定义书签。 软件质量指标度量 错误!未定义书签。 2软件质量指标 2 .1?需求功能点覆盖率？错误 味定义书签。 2 .2?用例执行覆盖率潴误味定义书签。 2 .3?缺陷修复率（截至于**年*月*日）?错误!未定义书签。 2.4?缺陷遗留个数（截至于* *年*月*日）?错误 味定义书签。 27?缺陷密度及收敛 3测试过程质量指标？错误!未定义书签。 3. 1 缺陷探测率 3 .2?有效缺陷率11? 4. 2 故障回退率 1综述 1.1 编写目的？错误!未定义书签。 1.2 阅读指南？错误!未定义书签。 错误!未定义书签。 2 .5?缺陷分布统计（模块缺陷率） 错误!未定义书签。 2.6 缺陷分布统计（严重缺陷率 ） 错误!未定义书签。 错误!未定义书签。 错误!未定义书签。 3.1 用例执行效率 错误!未定义书签。 3.2 缺陷发现率12? 4?交付质量指标 错误!未定义书签。 错误!未定义书签。
5?版本说明?错误!未定义书签。 作者:
1综述 1.1编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经 理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。 1.2阅读指南 软件测试质量指标主要针对研发项目、商务项目被测产品出具数据度量。 测试过程质量指标主要为测试经理、测试组长对测试人员的测试执行质量出具数 据度量。 交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用，也可结合使用。
软件评价指标
软件评价指标 文件管理序列号：[K8UY-K9IO69-O6M243-OL889-F88688]
我们常说某某软件好用，某软件功能全、结构合理、层次分明。这些表述很含糊，用来评价软件质量不够确切，不能作为企业选购软件的依据。对于企业来说，开发单位按照企业的需求，开发一个应用软件系统，按期完成并移交使用，系统正确执行用户规定的功能，仅仅满足这些是远远不够的。因为企业在引进一套软件过程中，常常会出现如下问题： ● 定制的软件可能难于理解，难于修改，在维护期间，企业的维护费用大幅度增加； ● 企业对外购的软件质量存在怀疑，企业评价软件质量没有一个恰当的指标，对软件可靠性和功能性指标了解不足； ● 软件开发商缺乏历史数据作为指南，所有关于进度和成本的估算都是粗略的。因为没有切实的生产率指标，没有过去关于软件开发过程的数据，企业无法精确评价开发商的工作质量。 为此，有必要先了解软件的质量评价体系。美国的B.W.Ｂoehm和R.Brown 先后提出了三层次的评价度量模型：软件质量要素、准则、度量。随后G.Mruine 提出了自己的软件质量度量SQM技术，波音公司在软件开发过程中采用了SQM 技术，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在成本控制和进度安排方面取得了良好的效果。 第一层是软件质量要素，软件质量可分解成六个要素，这六个要素是软件的基本特征： 1. 功能性：软件所实现的功能满足用户需求的程度．功能性反映了所开发的软件满足用户称述的或蕴涵的需求的程度，即用户要求的功能是否全部实现了。 2. 可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度。可靠
软件开发度量及考核方法
软件开发度量及考核方法 一、引言 如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。虽然目前很多公司有这方面的绩效考核，但是由于软件开发行业的特殊性，大多数公司没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。所以根据以前经验和相关的资料编写了适用于本部门的度量和考核方法。该考核方法是技术支持部软件开发人员和测试人员的试行版本。 二、目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 三、考核实施办法 1、定义 1.1 、软件项包括 1）、技术文档："软件工程产品集"所确定的配置项。主要包括：用户需求文档、需求分析文档、概要设计文档、详细设计文档、开发计划、测试文档、用户手册、总结报告等。 2）、计算机程序。 1.2 、度量数据的来源 1）、项目计划：过程度量中及时度考核数据的主要依据。 2）、测试文档：计算机程序质量考核数据主要依据。 3）、软件维护记录：主要是指软件产品投入用户使用后产生的软件维护记录。
2、质量度量 2.1度量指标 主要根据各类软件项检查表的检查指标来确定。例如，详细设计说明书检查表有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。（本文末尾附了各工作阶段的考核检查指标表） 2.2质量等级 1）软件项的质量等级的确定根据度量综合指标进行。 2）度量综合指标计算公式为： Total =刀QiMi。 3）其中i=1,2,...n 代表指标数量； 4）Q代表度量的指标； 5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。
软件质量评估办法
软件质量评估办法 Final approval draft on November 22, 2020
软件系统质量 记分办法，可以按照月，季或者年进行记分合计，每分对应相应的价格进行奖惩。 上线前 需求覆盖率，至少95%； 问题遗留率，最高5%； 严重BUG比率，最高10%； 试运行过程 初期故障率：指软件在初期故障期（一般以软件交付给用户后的三个月内为初期故障期）内单位时间的故障数。一般以每100小时的故障数为单位。可以用它来评价交付使用的软件质量与预测什么时候软件可靠性基本稳定。初期故障率的大小取决于软件设计水平、检查项目数、软件规模、软件调试彻底与否等因素 偶然故障率：指软件在偶然故障期（一般以软件交付给用户后的四个月以后为偶然故障期）内单位时间的故障数。一般以每1000小时的故障数为单位，它反映了软件处于稳定状态下的质量 运维过程 平均失效间隔时间（MTBF） 指软件在相继两次失效之间正常工作的平均统计时间。在实际使用时，MTBF通常是指当n很大时，系统第n次失效与第n+1次失效之间的平均统计时间。 国外一般民用软件的MTBF大体在1000小时左右。对于可靠性要求高的软件，则要求在1000~10000小时之间。 考核办法：小于1000小时，记10分； 小于500小时，记20分； 小于200小时，记30分； 小于100小时，记50分并记严重缺陷。 易用性指标 易用性可通过多方评审来确定，分优秀、良好、一般、较差、极差；较差，记10分；极差记20分并需进行整改。
性能质量 吞吐率 单位时间软件的信息处理能力（即各种目标的处理批数）。软件必须具有处理海量数据的能力。吞吐率就是体现该能力的参数。随着信息的泛滥，要求软件的吞吐率应该达到数百批 最大并发用户数 系统在用户使用峰值时能够承载的最大用户使用数量，需要通过测试确定，也可由用户指定，通常如果100用户数量，采用8020原则计算得到每小时峰值活动用户数 /小时性能每下降5%，记10分，下降超过30%记30分，并需要性能调优。 响应时间 稳定性 平均失效恢复时间 指软件失效后恢复正常工作所需的平均统计时间。对于软件，其失效恢复时间为排除故障或系统重新启动所用的时间，而不是对软件本身进行修改的时间（因软件已经固化在机器内，修改软件势必涉及重新固化问题，而这个过程的时间是无法确定的）。 1小时以内，记1分 2小时以内，记2分 5小时以内，记3分 8小时以内，记5分 超过8小时，记10分，并记为严重故障。
软件评价指标
我们常说某某软件好用,某软件功能全、结构合理、层次分明。这些表述很含糊,用来评价软件质量不够确切,不能作为企业选购软件的依据。对于企业来说,开发单位按照企业的需求,开发一个应用软件系统,按期完成并移交使用,系统正确执行用户规定的功能,仅仅满足这些就是远远不够的。因为企业在引进一套软件过程中,常常会出现如下问题: ● 定制的软件可能难于理解,难于修改,在维护期间,企业的维护费用大幅度增加; ● 企业对外购的软件质量存在怀疑,企业评价软件质量没有一个恰当的指标,对软件可靠性与功能性指标了解不足; ●软件开发商缺乏历史数据作为指南,所有关于进度与成本的估算都就是粗略的。因为没有切实的生产率指标,没有过去关于软件开发过程的数据,企业无法精确评价开发商的工作质量。 为此,有必要先了解软件的质量评价体系。美国的B、W、Ｂoehm与R、Brown 先后提出了三层次的评价度量模型:软件质量要素、准则、度量。随后G、Mruine提出了自己的软件质量度量SQM技术,波音公司在软件开发过程中采用了SQM技术,日本的NEC公司也提出了自己的SQM工具,即SQMAT,并且在成本控制与进度安排方面取得了良好的效果。 第一层就是软件质量要素,软件质量可分解成六个要素,这六个要素就是软件的基本特征: 1、功能性:软件所实现的功能满足用户需求的程度.功能性反映了所开发的软件满足用户称述的或蕴涵的需求的程度,即用户要求的功能就是否全部实现了。 2、可靠性:在规定的时间与条件下,软件所能维持其性能水平的程度。可靠性对某些软件就是重要的质量要求,它除了反映软件满足用户需求正常运行的程度,且反映了在故障发生时能继续运行的程度。 3、易使用性:对于一个软件,用户学习、操作、准备输入与理解输出时,所做努力的程度。易使用性反映了与用户的友善性,即用户在使用本软件时就是否方便。 4、效率:在指定的条件下,用软件实现某种功能所需的计算机资源(包括时间)的有效程度。效率反映了在完成功能要求时,有没有浪费资源,此外＂资源"这个术语有比较广泛的含义,它包括了内存、外存的使用,通道能力及处理时间。 5、可维修性:在一个可运行软件中,为了满足用户需求、环境改变或软件错误发生时,进行相应修改所做的努力程度。可维修性反映了在用户需求改变或软件环境发生变更时,对软件系统进行相应修改的容易程度。一个易于维护的软件系统也就是一个易理解、易测试与易修改的软件,以便纠正或增加新的功能,或允许在不同软件环境上进行操作。 6、可移植性:从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度。
软件质量国家标准GB(质量管理度量)
软件质量国家标准GB-T8566--2001G,软件质量要素: 1.功能性-与一组功能及其指定性质有关的一组属性,这里的功能是满足明确或隐含的需求的那些功能.包含: a.完备性-软件功能完整,齐全有关的软件属性. b.正确性-能否得到正确或相符结果或效果有关的软件属性 2.可靠性-在规定的一段时间和条件下,与软件维持其性能水平的能力有关的一组属性.包含: a.可用度-软件运行后在任一随机时刻需要执行规定任务或完成规定功能时,软件处于可使用状态的概率. b.初期故障率-软件在初期故障期(一般为软件交付用户后的3个月)内单位时间(100小时)的故障数. c.偶然故障率-软件在偶然故障期(一般为软件交付用户后的4个月以后)内单位时间的故障数. d.平均失效前时间(MTTF)-软件在失效前正常工作的平均统计时间. e.平均失效间隔时间(MTBF)-软件在相继两次失效之间正常工作的平均统计时间.一般民用软件大体在1,000小时左右. f.缺陷密度(FD)-软件单位源代码(1,000行无注释)中隐藏的缺陷数量.典型统计表明,开发阶段平均50-60个缺陷/千行源码, 交付后平均15-18个缺陷/千行源码. g.平均失效恢复时间(MTTR)-软件失效后恢复正常工作所需的平均统计时间. 3.易用性-由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性.包含: a.易理解性-用户认识软件的逻辑概念及其应用范围所花的努力有关的软件属性. b.易学习性-用户为学习软件(运行控制,输入,输出等)所花的努力有关的软件属性. c.易操作性-用户为操作和运行控制所花的努力有关的软件属性 4.效率性-与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性.包含: a.输出结果更新周期-软件相邻两次输出结果的间隔时间. b.处理时间-软件完成某项功能(辅助计算或决策)所用的处理时间(不含人机交互的时间). c.吞吐量-单位时间软件的信息处理能力(各种目标的处理批数). d.代码规模-软件源程序的行数(不含注释), 属于软件的静态属性 5.可维护性-与进行指定的修改所需的努力有关的一组属性 6.可移植性-与软件从一个环境转移到另一个环境的能力有关的一组属性. 影响软件系统质量的4个关键技术要素 1.技术平台的寿命 2.试运行期 3.对于现有系统的迁移 4.技术扩展