软件质量评估办法

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件系统质量

记分办法,可以按照月,季或者年进行记分合计,每分对应相应的价格进行奖惩。

上线前

;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记

性能质量

吞吐率

。软件必须具有处理海量数据的能单位时间软件的信息处理能力(即各种目标的处理批数)

力。吞吐率就是体现该能力的参数。随着信息的泛滥,要求软件的吞吐率应该达到数百批

最大并发用户数

也可由用户指定,需要通过测试确定,系统在用户使用峰值时能够承载的最大用户使用数量,

通常如果小时6.667 /原则计算得到每小时峰值活动用户数20•80用户数量,采用100

分,并需要性能调优。30记30%分,下降超过10,记5%性能每下降

响应时间

页面响应时间处理办法用户体验效果

极佳3s

良好5s

一般8s

分1每个页面记很差以上10s

稳定性

平均失效恢复时间

其失效恢复时间为对于软件,指软件失效后恢复正常工作所需的平均统计时间。

(因软而不是对软件本身进行修改的时间排除故障或系统重新启动所用的时间,

而这个过程的时间是无修改软件势必涉及重新固化问题,件已经固化在机器内,

法确定的)。

分1小时以内,记1

分2小时以内,记2

分3小时以内,记5

分5小时以内,记8

小时,记8超过分,并记为严重故障。10

兼容性

系统兼容性

等,各种操作系统的版本也UNIX,LINUX,WIN系统能够对多种操作系统进行兼容,例如:

可定义;手机端软件同样适用。

考核办法

分;缺少两款以上可拒绝验收。50每缺少一款要求的兼容系统,记

应用兼容性

等;手360、遨游、CROME系列、火狐、IE架构软件,对浏览器需进行兼容,例如:B/S对

机端软件同样适用。

考核办法:每缺少一款要求的兼容浏览器,记分;缺少三款以上可拒绝验收。20

外设兼容性

与各种外设的兼容性,考核办法参见前面内容

版本间数据兼容性

考核办法不能出现高版本不兼容低版本数据的情况,系统升级过

程中各版本的数据兼容性,

参见前面内容

软件代码质量

率BUG代码

缺陷密度

一般情况下,通常以每千行无注解源代码为一个单位。指软件单位源代码中隐藏的缺陷数量。

的具体值。如果没有早期版本信息,也可以按照FD可以根据同类软件系统的早期版本估计

个缺50~60典型的统计表明,在开发阶段,平均每千行源代码有“通常的统计结果来估计。

。”个缺陷15~18陷,交付后平均每千行源代码有代码编写质量

代码规范符合度

分,1记每出现一处不符合规范的内容,代码编写内容是否按照代码编写规范进行编写,代

分并需要整改。100,记30%码编写内容满足规范少于

代码注释量

分20,记1:10分;10,记1:1,1:5理想情况为

开发过程质量

开发过程符合度

开发过程是否按照工期和流程进行。

人员考核

开发工程师

相关文档
最新文档