软件质量管理.docx
《软件质量管理.docx》由会员分享,可在线阅读,更多相关《软件质量管理.docx(17页珍藏版)》请在冰豆网上搜索。
软件质量管理
做软件“大餐”的工序
软件质量保证(SoftwareQualityAssurance,以下简称SQA)的目的是验证在软件开发过程中是否遵循了合适的过程和标准。
软件质量保证过程一般包含以下几项活动:
首先是建立SQA组;其次是选择和确定SQA活动,即选择SQA组所要进行的质量保证活动,这些SQA活动将作为SQA计划的输入;然后是制定和维护SQA计划,这个计划明确了SQA活动与整个软件开发生命周期中各个阶段的关系;还有执行SQA计划、对相关人员进行培训、选择与整个软件工程环境相适应的质量保证工具;最后是不断完善质量保证过程活动中存在的不足,改进项目的质量保证过程。
独立的SQA组是衡量软件开发活动优劣与否的尺度之一。
SQA组的这一独立性,使其享有一项关键权利——“越级上报”。
当SQA组发现产品质量出现危机时,它有权向项目组的上级机构直接报告这一危机。
这无疑对项目组起到相当的“威慑”作用,也可以看成是促使项目组重视软件开发质量的一种激励。
这一形式使许多问题在组内得以解决,提高了软件开发的质量和效率。
选择和确定SQA活动这一过程的目的是策划在整个项目开发过程中所需要进行的质量保证活动。
质量保证活动应与整个项目的开发计划和配置管理计划相一致。
一般把该活动分为以下五类:
1)评审软件产品、工具与设施
软件产品常被称为“无形”的产品。
评审时难度更大。
在此要注意的一点是:
在评审时不能只对最终的软件代码进行评审,还要对软件开发计划、标准、过程、软件需求、软件设计、数据库、手册以及测试信息等进行评审。
评估软件工具主要是为了保证项目组采用合适的技术和工具。
评估项目设施的目的是保证项目组有充足设备和资源进行软件开发工作。
这也为规划今后软件项目的设备购置、资源扩充、资源共享等提供依据。
2)SQA活动审查的软件开发过程
SQA活动审查的软件开发过程主要有:
软件产品的评审过程、项目的计划和跟踪过程、软件需求分析过程、软件设计过程、软件实现和单元测试过程、集成和系统测试过程、项目交付过程、子承包商控制过程、配置管理过程。
特别要强调的是,为保证软件质量,应赋予SQA阻止交付某些不符合项目需求和标准产品的权利。
3)参与技术和管理评审
参与技术和管理评审的目的是为了保证此类评审满足项目要求,便于监督问题的解决。
4)做SQA报告
SQA活动的一个重要内容就是报告对软件产品或软件过程评估的结果,并提出改进建议。
SQA应将其评估的结果文档化
5)做SQA度量
SQA度量是记录花费在SQA活动上时间、人力等数据。
通过大量数据的积累、分析,可以使企业领导对质量管理的重要性有定量的认识,利于质量管理活动的进一步开展。
要说明的是,并不是每个项目的质量保证过程都必须包含上述这些活动或仅限于这些活动,要根据项目的具体情况来定。
SQA计划中必须明确定义在软件开发的各个阶段是如何进行质量保证活动的。
它通常包含以下内容:
质量目标;定义每个开发阶段的开始和结束边界;详细策划要进行的质量保证活动;明确质量活动的职责;SQA组的职责和权限;SQA组的资源需求,包括人员、工具和设施;定义由SQA组执行的评估;定义由SQA组负责组织的评审;SQA组进行评审和检查时所参见的项目标准和过程;需由SQA组产生的文档。
选择合适的SQA工具并不是试图通过选择SQA工具来保证软件产品的质量,而是用以支持SQA的活动。
选定SQA工具时,首先需要明确质量保证目标。
根据目标制定选择SQA工具的需求并文档化,包括对平台、操作系统以及SQA工具与软件工程平台接口的要求等。
如何使白壁“无瑕”
按工序去做也不一定能得到一盘完美的“大餐”,因为火侯等因素实在很难掌握。
万一掌握不好怎么办?
软件质量控制主要就是发现和消除软件产品的缺陷。
对于高质量的软件来讲,最终产品应该尽可能达到零缺陷。
而软件开发是一个以人为中心的活动,所以出现缺陷是不可避免的。
因此,要想交付一个高质量的软件,消除缺陷的活动就变得很重要。
缺陷消除是通过“评审”和“测试”这类质量控制活动来实现的。
缺陷在软件开发的任何阶段都可能会被引入。
项目质量管理过程包含了许多可以识别缺陷、消除缺陷的过程。
“识别缺陷”和“消除缺陷”本来是两个不同的过程,但在这里为了简便统一用“消除”来代表它们。
潜在的缺陷越大,用来消除它所花的费用越高。
因此成熟的软件开发过程在每一个可能会引入潜在缺陷的阶段完成之后都会开展质量控制活动。
这些为了消除缺陷的活动包括:
需求评审、设计评审、代码走查、单元测试、集成测试、系统测试以及验收测试等。
质量控制的任务就是策划可行的质量管理活动,然后正确地执行和控制这些活动以保证绝大多数的缺陷可以在开发过程中被发现。
正如前面提到的,在进行评审和测试时可检测到缺陷。
评审是面向人的过程,测试是运行软件(或部分软件)以便发现缺陷。
在一个项目里,评审和测试活动是预先策划好的(计划书中确定执行哪些质量控制活动和何时执行这些活动)。
在执行过程中,根据已定义好的过程来执行这些活动。
通过执行这些活动来识别缺陷,然后消除这些缺陷。
例如,系统测试过程一般包括制定测试计划,测试计划中应列出在测试执行过程中所有的测试用例,评审测试计划,并且最终执行测试计划。
1.0目的
本文的目的是描述ABC中心的SQA组进行内部软件过程检查所使用的程序。
执行检查的目的是为了提供对软件过程的客观承诺确认,并最终提交满足标准、手册、规格书以及程序等方面要求的软件产品。
2.0范围
文中所描述的程序适用于ABC中心SQA组执行的内部软件过程检查。
3.0术语表
KPA:
关键过程域。
SEI:
软件工程研究所。
CMM:
能力成熟度模型。
SQA:
软件质量保证。
SCM:
软件配置管理。
SQAP:
软件质量保证计划。
4.0参考文献
[1]软件能力成熟度模型,1.1版,软件工程研究所,CMU/SEI-93-TR-24,February1993.
[2]APDSQA检查程序,APD-PR-SQA-AUD-001,Version1.0,Aug.21,1996.
5.0角色和职责
5.1检查者
检查者是指准备并执行检查的个人或小组。
成立一个检查小组以后,首先要指定一个检查小组领导。
检查小组领导负责为小组其他成员分配检查任务。
检查小组领导负责如下各项任务:
训练和调整检查小组成员。
规划检查中用到的人力和设备等资源。
执行检查。
生成检查报告。
发布检查报告。
跟踪检查纠正活动。
检查小组领导或者作为检查者的个人必须是SQA组的成员。
SQA组负责确保积极的纠正活动被执行,并文档化识别出的软件过程中的不符合项。
5.2被检查者
被检查者是指接受检查的团体或者小组。
被检查的团体或小组负责以下各项任务:
理解客观公正的检查标准。
与检查小组全力合作。
对检查报告做出响应,制定纠正活动计划。
5.3SQA代表
被检查方的SQA代表负责执行检查中的许多协调步骤,比如规划采访中涉及的人员和用到的会谈房间,协调自我评估,建立客观证据,对检查者的需求进行反馈,以及准备下一步的活动计划等。
5.4高层管理员
高层管理员负责监控检查过程的进展,并且在产生较大的矛盾时给予及时的辅助和调解。
6.0检查计划表
R&DSQA小组负责制订季度性的检查计划表。
整个计划表发布在R&DSQA主页,并且由SQA小组协调员负责维护。
当规划一次检查时,SQA小组将会指定其成员之一作为检查小组领导,被检查的小组则会周期性地收到该检查小组领导的一些通知。
检查小组领导是检查计划的所有者,他(她)负责参照检查程序来指导检查活动。
1.0目的
本文的目的是描述ABC中心的SQA组进行内部软件过程检查所使用的程序。
执行检查的目的是为了提供对软件过程的客观承诺确认,并最终提交满足标准、手册、规格书以及程序等方面要求的软件产品。
2.0范围
文中所描述的程序适用于ABC中心SQA组执行的内部软件过程检查。
3.0术语表
KPA:
关键过程域。
SEI:
软件工程研究所。
CMM:
能力成熟度模型。
SQA:
软件质量保证。
SCM:
软件配置管理。
SQAP:
软件质量保证计划。
4.0参考文献
[1]软件能力成熟度模型,1.1版,软件工程研究所,CMU/SEI-93-TR-24,February1993.
[2]APDSQA检查程序,APD-PR-SQA-AUD-001,Version1.0,Aug.21,1996.
5.0角色和职责
5.1检查者
检查者是指准备并执行检查的个人或小组。
成立一个检查小组以后,首先要指定一个检查小组领导。
检查小组领导负责为小组其他成员分配检查任务。
检查小组领导负责如下各项任务:
训练和调整检查小组成员。
规划检查中用到的人力和设备等资源。
执行检查。
生成检查报告。
发布检查报告。
跟踪检查纠正活动。
检查小组领导或者作为检查者的个人必须是SQA组的成员。
SQA组负责确保积极的纠正活动被执行,并文档化识别出的软件过程中的不符合项。
5.2被检查者
被检查者是指接受检查的团体或者小组。
被检查的团体或小组负责以下各项任务:
理解客观公正的检查标准。
与检查小组全力合作。
对检查报告做出响应,制定纠正活动计划。
5.3SQA代表
被检查方的SQA代表负责执行检查中的许多协调步骤,比如规划采访中涉及的人员和用到的会谈房间,协调自我评估,建立客观证据,对检查者的需求进行反馈,以及准备下一步的活动计划等。
5.4高层管理员
高层管理员负责监控检查过程的进展,并且在产生较大的矛盾时给予及时的辅助和调解。
6.0检查计划表
R&DSQA小组负责制订季度性的检查计划表。
整个计划表发布在R&DSQA主页,并且由SQA小组协调员负责维护。
当规划一次检查时,SQA小组将会指定其成员之一作为检查小组领导,被检查的小组则会周期性地收到该检查小组领导的一些通知。
检查小组领导是检查计划的所有者,他(她)负责参照检查程序来指导检查活动。
软件开发质量管理层次模型
(1)
作者:
来源:
阅读1599人次 , 2006-4-190:
59:
00
1概述
质量:
一组固有特性满足要求的程度,指产品或服务满足规定或潜在需要的特征和特性的总和。
它既包括有形产品也包括无形产品;既包括产品内在的特性、也包括产品外在的特性。
即包括了产品的适用性和符合性的全部内涵。
软件质量:
与软件产品满足明确或隐含需求的能力有关的特征和特征的总和。
有四个含义:
1、能满足给定需要的特性之全体;2、具有所希望的各种属性的组合的程度;3、顾客或用户认为能满足其综合期望的程度;4、软件的组合特性,它确定软件在使用中将满足顾客预期要求的程度。
从用户最感兴趣的的角度来说,软件质量可以从三个不同的角度来看待:
如何使用软件、使用效果如何、软件性能如何;从软件开发的团队的角度来说,不仅要生产出满足质量要求的软件,也对中间产品的质量感兴趣,也对如何运用最少的的资源、最快的进度生产出质量最优的产品感兴趣;从软件维护者的角度看,对软件维护方面的特性感兴趣;对企业的管理层来说,注重的是总体效益和长远利益,就是说质量好的软件一般可以帮助企业扩大市场;反之,质量差的软件一般会造成企业市场萎缩。
软件质量特性:
根据《GB/T16260-1996(idtISO/IEC9126:
1991)信息技术软件产品评价质量特性及其使用指南》软件的质量特性包括功能性、可靠性、易用性、效率、可维护性、可移植性等六个方面,每个方面都包含若干个子特性:
功能性:
适合性、准确性、互操作性、依从性、安全性;
可靠性:
成熟性、容错性、易恢复性;
易用性:
易理解性、易学性、易操作性;
效率:
时间特性、资源特性;
可维护性:
易分析性、易改变性、稳定性、易测试性;
可移植性:
适应性、易安装性、遵循性、易替换性;
质量管理:
在质量方面指挥和控制组织的协调的活动,指对确定和达到质量所必须的全总职能和活动的管理,其管理职能主要包括制定质量方针和质量目标以及质量策划、质量控制、质量保证和质量改进。
软件开发质量管理,就是为了开发出符合质量要求的软件产品,贯穿于软件开发生存期过程的质量管理工作。
软件开发质量管理层次初步划分如下:
1、技术层次(数据、编程、文档)
2、方法体系层次(措施、项目、过程)
3、社会因素层次(质量环境、技术标准、业务标准、人员)
软件开发质量管理层次模型如下图:
2技术层次
2.1数据质量管理层次
多数情况下,软件系统的最终目的是对用户关心的各类数据(信息)完成各种各样静态或者动态的处理或管理任务,为用户创造他们所期望和额外的价值。
因此数据质量是用户最为关心的,数据质量也反映了软件系统产品的质量。
数据质量是数据抽取、数据转换、数据整合、数据仓库以及管理信息系统开发等项目中质量控制和质量保证必须考虑的主要工作。
数据质量管理可分为人工比对、程序比对、统计分析三个层次。
2.1.1人工比对
为了检查数据的正确性,测试人员打开相关数据库,对转换前和转换后的数据进行直接的比对,发现其不一致性,通知相关人员进行纠正。
2.1.2程序比对
为了自动化地检查数据的质量,更好地进行测试对比,程序员编写查询比对程序给测试人员使用。
测试人员使用此程序对转换前和转换后的数据进行比对,发现其不一致性,通知相关人员进行纠正。
2.1.3统计分析
为了更加全面地从总体上检查数据的质量,需要通过统计分析的方法,主要通过对新旧数据不同角度、不同视图的统计对数据转换的正确程度进行量化的分析,发现其在某个统计结果的不一致性,通知相关人员进行纠正。
2.2编程质量管理层次
软件系统是靠“编”出来的,为了确保软件产品的质量,就必须确保软件程序代码的质量。
为了提高编程质量,应检查源码的逻辑、属性、对象命名标准、语言代码布局等内容;代码的编译、链接、集成和构建必须得到验证和确认。
编程质量管理层次可分为黑盒测试、灰盒测试、白盒测试、编译检查、编程规范、编程逻辑、编程优化。
2.2.1黑盒测试
黑盒测试检验是否符合系统需求,也称功能测试或数据驱动测试。
它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用。
在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。
2.2.2灰盒测试
灰盒测试介于白盒与黑盒二者之间,关注输出对于输入的正确性,同时也关注内部表现,但这种关注不像白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。
2.2.3白盒测试
白盒测试也称结构测试或逻辑驱动测试,它是在知道产品内部工作过程的情况下,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能。
白盒测试的主要方法有逻辑驱动、基路测试等。
2.2.4编译检查
使用开发工具所带的编译功能或专门程序对软件源码进行检查,分析和寻找源码存在的问题。
2.2.5编程规范
通过人工源码检查判断源码是否符合企业已经制定的相关编程规范。
制定编程规范,在企业内形成一个开发约定和规则,有利于整体风格统一、代码的可读性、可维护性和可扩展性。
2.2.6编程逻辑
所编写的源码是否考虑周全,无矛盾或遗漏之处。
常见问题如:
忘记定义变量就使用、变量没有赋值初就直接使用、输入输出的数据类型与所用格式说明符不一致、没有注意数据的数值范围造成数组越界或数据溢出、输入时数组的组织方式与要求不符、循环语句可能会造成死循环、条件语句只考虑符合的情况而没有考虑例外的情况、读取文件或数据库中的数据没有考虑例外情况,等等。
2.2.7编程优化
通过人工或软件检查判断是否可进一步提高源码总体性能和运行可管理性。
总体性能如内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响等等;运行可管理性如便于控制系统运行、监视系统状态、错误处理;模块间通信的简单性等等。
1概述
质量:
一组固有特性满足要求的程度,指产品或服务满足规定或潜在需要的特征和特性的总和。
它既包括有形产品也包括无形产品;既包括产品内在的特性、也包括产品外在的特性。
即包括了产品的适用性和符合性的全部内涵。
软件质量:
与软件产品满足明确或隐含需求的能力有关的特征和特征的总和。
有四个含义:
1、能满足给定需要的特性之全体;2、具有所希望的各种属性的组合的程度;3、顾客或用户认为能满足其综合期望的程度;4、软件的组合特性,它确定软件在使用中将满足顾客预期要求的程度。
从用户最感兴趣的的角度来说,软件质量可以从三个不同的角度来看待:
如何使用软件、使用效果如何、软件性能如何;从软件开发的团队的角度来说,不仅要生产出满足质量要求的软件,也对中间产品的质量感兴趣,也对如何运用最少的的资源、最快的进度生产出质量最优的产品感兴趣;从软件维护者的角度看,对软件维护方面的特性感兴趣;对企业的管理层来说,注重的是总体效益和长远利益,就是说质量好的软件一般可以帮助企业扩大市场;反之,质量差的软件一般会造成企业市场萎缩。
软件质量特性:
根据《GB/T16260-1996(idtISO/IEC9126:
1991)信息技术软件产品评价质量特性及其使用指南》软件的质量特性包括功能性、可靠性、易用性、效率、可维护性、可移植性等六个方面,每个方面都包含若干个子特性:
功能性:
适合性、准确性、互操作性、依从性、安全性;
可靠性:
成熟性、容错性、易恢复性;
易用性:
易理解性、易学性、易操作性;
效率:
时间特性、资源特性;
可维护性:
易分析性、易改变性、稳定性、易测试性;
可移植性:
适应性、易安装性、遵循性、易替换性;
质量管理:
在质量方面指挥和控制组织的协调的活动,指对确定和达到质量所必须的全总职能和活动的管理,其管理职能主要包括制定质量方针和质量目标以及质量策划、质量控制、质量保证和质量改进。
软件开发质量管理,就是为了开发出符合质量要求的软件产品,贯穿于软件开发生存期过程的质量管理工作。
软件开发质量管理层次初步划分如下:
1、技术层次(数据、编程、文档)
2、方法体系层次(措施、项目、过程)
3、社会因素层次(质量环境、技术标准、业务标准、人员)
软件开发质量管理层次模型如下图:
2技术层次
2.1数据质量管理层次
多数情况下,软件系统的最终目的是对用户关心的各类数据(信息)完成各种各样静态或者动态的处理或管理任务,为用户创造他们所期望和额外的价值。
因此数据质量是用户最为关心的,数据质量也反映了软件系统产品的质量。
数据质量是数据抽取、数据转换、数据整合、数据仓库以及管理信息系统开发等项目中质量控制和质量保证必须考虑的主要工作。
数据质量管理可分为人工比对、程序比对、统计分析三个层次。
2.1.1人工比对
为了检查数据的正确性,测试人员打开相关数据库,对转换前和转换后的数据进行直接的比对,发现其不一致性,通知相关人员进行纠正。
2.1.2程序比对
为了自动化地检查数据的质量,更好地进行测试对比,程序员编写查询比对程序给测试人员使用。
测试人员使用此程序对转换前和转换后的数据进行比对,发现其不一致性,通知相关人员进行纠正。
2.1.3统计分析
为了更加全面地从总体上检查数据的质量,需要通过统计分析的方法,主要通过对新旧数据不同角度、不同视图的统计对数据转换的正确程度进行量化的分析,发现其在某个统计结果的不一致性,通知相关人员进行纠正。
2.2编程质量管理层次
软件系统是靠“编”出来的,为了确保软件产品的质量,就必须确保软件程序代码的质量。
为了提高编程质量,应检查源码的逻辑、属性、对象命名标准、语言代码布局等内容;代码的编译、链接、集成和构建必须得到验证和确认。
编程质量管理层次可分为黑盒测试、灰盒测试、白盒测试、编译检查、编程规范、编程逻辑、编程优化。
2.2.1黑盒测试
黑盒测试检验是否符合系统需求,也称功能测试或数据驱动测试。
它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用。
在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。
2.2.2灰盒测试
灰盒测试介于白盒与黑盒二者之间,关注输出对于输入的正确性,同时也关注内部表现,但这种关注不像白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。
2.2.3白盒测试
白盒测试也称结构测试或逻辑驱动测试,它是在知道产品内部工作过程的情况下,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能。
白盒测试的主要方法有逻辑驱动、基路测试等。
2.2.4编译检查
使用开发工具所带的编译功能或专门程序对软件源码进行检查,分析和寻找源码存在的问题。
2.2.5编程规范
通过人工源码检查判断源码是否符合企业已经制定的相关编程规范。
制定编程规范,在企业内形成一个开发约定和规则,有利于整体风格统一、代码的可读性、可维护性和可扩展性。
2.2.6编程逻辑
所编写的源码是否考虑周全,无矛盾或遗漏之处。
常见问题如:
忘记定义变量就使用、变量没有赋值初就直接使用、输入输出的数据类型与所用格式说明符不一致、没有注意数据的数值范围造成数组越界或数据溢出、输入时数组的组织方式与要求不符、循环语句可能会造成死循环、条件语句只考虑符合的情况而没有考虑例外的情况、读取文件或数据库中的数据没有考虑例外情况,等等。
2.2.7编程优化
通过人工或软件检查判断是否可进一步提高源码总体性能和运行可管理性。
总体性能如内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响等等;运行可管理性如便于控制系统运行、监视系统状态、错误处理;模块间通信的简单性等等。
1概述
质量:
一组固有特性满足要求的程度,指产品或服务满足规定或潜在需要的特征和特性的总和。
它既包括有形产品也包括无形产品;既包括产品内在的特性、也包括产品外在的特性。
即包括了产品的适用性和符合性的全部内涵。
软件质量:
与软件产品满足明确或隐含需求的能力有关的特征和特征的总和。
有四个含义:
1、能满足给定需要的特性之全体;2、具有所希望的各种属性的组合的程度;3、顾客或用户认为能满足其综合期望的程度;4、软件的组合特性,它确定软件在使用中将满足