软件质量评估办法
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件质量评估办法 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分,并记为严重故障。
兼容性
系统兼容性
系统能够对多种操作系统进行兼容,例如: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分
开发过程质量
开发过程符合度
开发过程是否按照工期和流程进行。
人员考核
开发工程师
测试工程师
运维工程师