本文对软件开发质量管理的层次进行了初步的划分,形成了软件开发质量管理层次模型,并对模型中的各个层次内涵做了简要说明。
1 概述
质量:一组固有特性满足要求的程度,指产品或服务满足规定或潜在需要的特征和特性的总和。它既包括有形产品也包括无形产品;既包括产品内在的特性、也包括产品外在的特性。即包括了产品的适用性和符合性的全部内涵。
软件质量:与软件产品满足明确或隐含需求的能力有关的特征和特征的总和。有四个含义:1、能满足给定需要的特性之全体;2、具有所希望的各种属性的组合的程度;3、顾客或用户认为能满足其综合期望的程度;4、软件的组合特性,它确定软件在使用中将满足顾客预期要求的程度。
从用户最感兴趣的的角度来说,软件质量可以从三个不同的角度来看待:如何使用软件、使用效果如何、软件性能如何;从软件开发的团队的角度来说,不仅要生产出满足质量要求的软件,也对中间产品的质量感兴趣,也对如何运用最少的的资源、最快的进度生产出质量最优的产品感兴趣;从软件维护者的角度看,对软件维护方面的特性感兴趣;对企业的管理层来说,注重的是总体效益和长远利益,就是说质量好的软件一般可以帮助企业扩大市场;反之,质量差的软件一般会造成企业市场萎缩。
软件质量特性:根据《GB/T16260-1996(idt ISO/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 编程优化
通过人工或软件检查判断是否可进一步提高源码总体性能和运行可管理性。总体性能如内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响等等;运行可管理性如便于控制系统运行、监视系统状态、错误处理;模块间通信的简单性等等。
2.3 文档质量管理层次
文档(包括模型)是软件开发过程中的中间成果,这些中间结果关系到软件需求的准确性完整性、设计的合理性,对软件系统的最终结果有决定性作用。文档质量管理层次包括文档规范、文档语法、文档语义、文档逻辑、文档美学、文档优化。
2.3.1 文档规范
文档成果符合企业或业界已经制定的文档模板规范。企业甚至行业应当制定统一的文档规范,形成一个文档约定和规则,以统一文档内容与风格。
2.3.2 文档语法
文档成果正确使用通用的工具与术语、符合相关行业的技术标准。所有语言都有它的语法,所有质量合格的文档(包括模型)都应该是语法正确的,不正确的语法会影响规格说明和可视化的质量。
2.3.3 文档语义
文档成果表达正确、无歧义。所有质量合格的文档(包括模型)都代表它期望代表的语义,而且应该在代表这些语义的时候具有一致性。
2.3.4 文档逻辑
文档成果考虑周全,不矛盾,满足客户的关键要求,特别是要符合相关行业的业务标准。
2.3.5 文档美学
文档成果是最佳表述,文字、图表是均衡和完整的。就是追求平衡的美,每个组成部分应该不大不小,可解读、可变更、不同时代表太多的元素。
2.3.6 结果优化
通过检查判断文档成果(如项目计划、需求规格、设计方案)是否还有改进的空间,以尽可能达到最佳方案。任何一项设计,都可以有许多不同的方案,通过“方案优化”选定一种最好的方案。
任何一位设计师在做一项设计的时候总是选择他认为是最好的方案,都有某种程度上的“优化”,因此他可以说他的产品是经过“优化”的。无论何种意义上的优化,都有一个共同的特点,就是相对性。这个相对性有两方面的意义,一是优化是相对某种目标的,目标不同优化的结果不同。另一方面是在大多数的情况下,优化的结果并不是最优的,只能是相对好的。
[@more@]
1 概述
质量:一组固有特性满足要求的程度,指产品或服务满足规定或潜在需要的特征和特性的总和。它既包括有形产品也包括无形产品;既包括产品内在的特性、也包括产品外在的特性。即包括了产品的适用性和符合性的全部内涵。
软件质量:与软件产品满足明确或隐含需求的能力有关的特征和特征的总和。有四个含义:1、能满足给定需要的特性之全体;2、具有所希望的各种属性的组合的程度;3、顾客或用户认为能满足其综合期望的程度;4、软件的组合特性,它确定软件在使用中将满足顾客预期要求的程度。
从用户最感兴趣的的角度来说,软件质量可以从三个不同的角度来看待:如何使用软件、使用效果如何、软件性能如何;从软件开发的团队的角度来说,不仅要生产出满足质量要求的软件,也对中间产品的质量感兴趣,也对如何运用最少的的资源、最快的进度生产出质量最优的产品感兴趣;从软件维护者的角度看,对软件维护方面的特性感兴趣;对企业的管理层来说,注重的是总体效益和长远利益,就是说质量好的软件一般可以帮助企业扩大市场;反之,质量差的软件一般会造成企业市场萎缩。
软件质量特性:根据《GB/T16260-1996(idt ISO/IEC9126:1991)信息技术 软件产品评价
质量特性及其使用指南》软件的质量特性包括功能性、可靠性、易用性、效率、可维护性、可移植性等六个方面,每个方面都包含若干个子特性:
功能性:适合性、准确性、互操作性、依从性、安全性;
可靠性:成熟性、容错性、易恢复性;
易用性:易理解性、易学性、易操作性;
效率:时间特性、资源特性;
可维护性:易分析性、易改变性、稳定性、易测试性;
可移植性:适应性、易安装性、遵循性、易替换性;
质量管理:在质量方面指挥和控制组织的协调的活动,指对确定和达到质量所必须的全总职能和活动的管理,其管理职能主要包括制定质量方针和质量目标以及质量策划、质量控制、质量保证和质量改进。
软件开发质量管理,就是为了开发出符合质量要求的软件产品,贯穿于软件开发生存期过程的质量管理工作。
软件开发质量管理层次初步划分如下:
1、技术层次(数据、编程、文档)
2、方法体系层次(措施、项目、过程)
3、社会因素层次(质量环境、技术标准、业务标准、人员)
软件开发质量管理层次模型如下图:
![200651594114664.gif](http://www.leadge.com/publish/images/200651594114664.gif)
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 编程优化
通过人工或软件检查判断是否可进一步提高源码总体性能和运行可管理性。总体性能如内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响等等;运行可管理性如便于控制系统运行、监视系统状态、错误处理;模块间通信的简单性等等。
2.3 文档质量管理层次
文档(包括模型)是软件开发过程中的中间成果,这些中间结果关系到软件需求的准确性完整性、设计的合理性,对软件系统的最终结果有决定性作用。文档质量管理层次包括文档规范、文档语法、文档语义、文档逻辑、文档美学、文档优化。
2.3.1 文档规范
文档成果符合企业或业界已经制定的文档模板规范。企业甚至行业应当制定统一的文档规范,形成一个文档约定和规则,以统一文档内容与风格。
2.3.2 文档语法
文档成果正确使用通用的工具与术语、符合相关行业的技术标准。所有语言都有它的语法,所有质量合格的文档(包括模型)都应该是语法正确的,不正确的语法会影响规格说明和可视化的质量。
2.3.3 文档语义
文档成果表达正确、无歧义。所有质量合格的文档(包括模型)都代表它期望代表的语义,而且应该在代表这些语义的时候具有一致性。
2.3.4 文档逻辑
文档成果考虑周全,不矛盾,满足客户的关键要求,特别是要符合相关行业的业务标准。
2.3.5 文档美学
文档成果是最佳表述,文字、图表是均衡和完整的。就是追求平衡的美,每个组成部分应该不大不小,可解读、可变更、不同时代表太多的元素。
2.3.6 结果优化
通过检查判断文档成果(如项目计划、需求规格、设计方案)是否还有改进的空间,以尽可能达到最佳方案。任何一项设计,都可以有许多不同的方案,通过“方案优化”选定一种最好的方案。
任何一位设计师在做一项设计的时候总是选择他认为是最好的方案,都有某种程度上的“优化”,因此他可以说他的产品是经过“优化”的。无论何种意义上的优化,都有一个共同的特点,就是相对性。这个相对性有两方面的意义,一是优化是相对某种目标的,目标不同优化的结果不同。另一方面是在大多数的情况下,优化的结果并不是最优的,只能是相对好的。
[@more@]
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7839396/viewspace-961180/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/7839396/viewspace-961180/