篇一：如何评价软件的质量
如何评价软件的质量
我们常说某某软件好用，某软件功能全、结构合理、层次分明。这些表述很含糊，用来评价软件质量不够确切，不能作为企业选购软件的依据。对于企业来说，开发单位按照企业的需求，开发一个应用软件系统，按期完成并移交使用，系统正确执行用户规定的功能，仅仅满足这些是远远不够的。因为企业在引进一套软件过程中，常常会出现如下问题： ?
? 定制的软件可能难于理解，难于修改，在维护期间，企业的维护费用大幅度增加； 企业对外购的软件质量存在怀疑，企业评价软件质量没有恰当的指标，对软件可靠性和功能性指标了解不足；
? 软件开发商缺乏历史数据作为指南，所有关于进度和成本的估算都是粗略的。因为没有切实的生产率指标，没有过去关于软件开发过程的数据，企业无法精确评价开发商的工作质量。
为此，有必要先了解软件的质量评价体系。美国的B.W.Ｂoehm和R.Brown 先后提出了三层次的评价度量模型：软件质量要素、准则、度量。随后G.Mruine提出了自己的软件质量度量SQM技术，波音公司在软件开发过程中采用了SQM技术，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在成本控制和进度安排方面取得了良好的效果。 第一层是软件质量要素，软件质量可分解成六个要素，这六个要素是软件的基本特征：
1. 功能性：软件所实现的功能满足用户需求的程度．功能性反映了所开发的软件满足用户称述的或蕴涵的需求的程度，即用户要求的功能是否全部实现了。
2. 可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度。可靠性对某些软件是重要的质量要求，它除了反映软件满足用户需求正常运行的程度，且反映了在故障发生时能继续运行的程度。
3. 易使用性：对于一个软件，用户学习、操作、准备输入和理解输出时，所做努力的程度。易使用性反映了与用户的友善性，即用户在使用本软件时是否方便。
4. 效率：在指定的条件下，用软件实现某种功能所需的计算机资源（包括时间）的有效程度。效率反映了在完成功能要求时，有没有浪费资源，此外＂资?quot;这个术语有比较广泛的含义，它包括了内存、外存的使用，通道能力及处理时间。
5. 可维修性：在一个可运行软件中，为了满足用户需求、环境改变或软件错误发生时，进行相应修改所做的努力程度。可维修性反映了在用户需求改变或软件环境发生变更时，对软件系统进行相应修改的容易程度。一个易于维护的软件系统也是一个易理解、易测试和易修改的软件，以便纠正或增加新的功能，或允许在不同软件环境上进行操作。
6. 可移植性：从一个计算机系统或环境转移到另一个计算机系统或环境的容易程度。
篇二：软件质量评价内容
软件质量评价内容
软件产品质量的评价，即软件产品质量特性的检测与度量。
国家标准GB/T 16260《软件产品评价-质量特性及其使用指南》规定了软件产品的六个质量特性，并推荐了与之对应的27个子特性，质量特性和子特性列表如下：
根据质量特性和子特性，我们将测试过程中的测试类型进行定义，定义为以下几类：1、 功能测试：
1） 针对需求验证功能是否实现（适合性，准确性，户操作性）2） 测试软件的出错处理能力（成熟性，容错性，易恢复性）
3） 测试软件的功能是否易用（易理解性，易学性，易操作性，吸引性）
4） 软件多种平台及环境下的兼容性测试（适应性，易安装性，共存性，易替换性）
5） 软件的可维护性测试（易分析性，易改变性，易测试性，稳定性）2、 安全测试：验证软件的安全保密性。1） 用户授权级别安全2） 承受攻击级别安全3） 数据信息泄露级别安全
3、 性能测试：测试软件运行是否满足用户给定的性能级别。（时间特性，资源特性）1） 服务器资源占用率测试，客户端资源占用率测试，网络资源占用率（资源特性）2） 规定的条件下，软件产品执行其功能时，提供适当的相应时间和处理时间以及吞吐率的能力
篇三：软件质量评估办法
软件系统质量
记分办法，可以按照月，季或者年进行记分合计，每分对应相应的价格进行奖惩。 上线前
需求覆盖率，至少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分
开发过程质量
开发过程符合度
开发过程是否按照工期和流程进行。
人员考核
开发工程师
测试工程师
运维工程师
《软件质量评价标准》由：创业找项目整理
链接地址：http://www.gjknj.com/duwu/2934.html
转载请保留,谢谢!