软件质量管理与控制.docx
《软件质量管理与控制.docx》由会员分享,可在线阅读,更多相关《软件质量管理与控制.docx(12页珍藏版)》请在冰点文库上搜索。
软件质量管理与控制
第8章软件质量管理与控制
第一章8.1目的
软件质量管理的目的是通过分析质量要素和质量目标,制定合适的质量计划,整合技术评审、软件测试、质量保证、缺陷(或问题)跟踪等手段,保证软件开发质量。
第二章8.2关键活动与流程
软件质量管理的流程如图8-1所示,关键活动是“制定质量计划”、“技术评审”、“软件测试”、“质量保证”、“缺陷跟踪和问题跟踪”。
图8-1中,在技术评审、软件测试和质量保证活动中发现的缺陷和问题,都采用缺陷跟踪工具和问题跟踪工具来管理。
制定质量计划
缺陷跟踪
问题跟踪
软件测试
技术评审
质量保证
质量人员
开发人员测试人员
质量人员
图8-1软件质量管理的流程
该流程的主要工作成果见表8-1。
表8-1软件质量管理流程的主要工作成果
关键活动
主要工作成果
责任人
制定质量计划
《质量计划》
质量人员
技术评审
《技术评审报告》
软件开发人员
软件测试
《软件测试报告》
软件测试人员
质量保证
《质量保证报告》
质量人员
缺陷跟踪
缺陷报表
缺陷相关人员
问题
问题报表
问题相关人员
8.2.1制定质量计划
质量计划是软件质量管理的行动纲领,通常由项目经理和质量人员共同协商制定质量计划。
如果机构有独立的质量人员,那么由质量人员起草《质量计划》,递交给项目经理和质量经理审批。
如果机构没有独立的质量人员,那么项目经理兼任质量人员和质量经理的角色。
表8-2为《质量计划》的参考格式。
表8-2质量计划
XXX软件质量计划
1.质量要素和质量目标
提示:
从商业利益和技术角度判断哪些质量属性是本软件的质量要素,说明为什么,这样相关人员可以把精力集中在改善质量要素上。
给出各个质量要素的恰当目标,既要使客户感到满意,又要使开发方承受得起。
质量要素
优先级
目标、解释
2.技术评审计划
待评审的工作成果
评审时间
负责人
3.软件测试计划
测试活动名称
时间
负责人
详见《测试计划》
4.质量保证计划
过程域
主要检查项
时间或频度
负责人
5.缺陷(问题)跟踪工具
提示:
说明本项目采用何种缺陷(问题)跟踪工具,以及简要的使用约定。
6.审批意见
提示:
项目经理和质量经理审批计划
第三章8.2.2技术评审
技术评审的目的是通过同行专家对工作成果的评审进行讨论,尽早地发现工作成果中的缺陷,并帮助开发人员及时消除缺陷,从而有效地提高产品的质量。
技术评审的主要好处有:
☆通过消除工作成果的缺陷而提高产品的质量。
☆技术评审可以在任何开发阶段执行,不必等到软件可以运行之际,越早消除缺陷就越能降低开发成本。
☆开发人员能够及时地得到同行专家的帮助和指导,无疑会加深对工作成果的理解,更好地预防缺陷,一定程度上提高了开发生产率。
理论上讲,为了确保产品的质量,产品的所有工作成果都应当接受技术评审。
现实中,为了节约时间,允许人们有选择地对工作成果进行技术评审。
在制定质量计划的时候,应该确定技术评审计划。
技术评审是团体活动,一般地,机构没有专职的技术评审人员,当需要技术评审的时候临时组织人员就可以了。
质量人员应当参与重要的技术评审会议,这样既监督了技术评审,又加深对工作成果的了解。
技术评审的一般流程如图8-2所示。
Step2.举行评审会议
主持人宣读
作者介绍工作成果
识别缺陷和答辩
讨论缺陷解决方案
评审总结
Step1.准备评审
Step3.缺陷跟踪
图8-2技术评审的流程
第一步准备评审
☆评审主持人首先确定评审会议的时间、地点、设备和参加会议的人员名单(包括评审员、记录员、作者、旁听者等),并告知所有相关人员。
☆评审主持人把工作成果及相关材料、技术评审规程、检查等发给评审员。
☆评审员阅读(了解)工作成果及相关材料。
第二步举行评审会议
☆主持人宣讲本次评审会议的过程、重点、原则、时间限制等。
☆作者扼要地介绍工作成果。
☆评审员认真查找工作成果的缺陷。
作者回答评审员的问题,双方要对每个缺陷达成共识。
☆作者和评审员共同讨论缺陷的解决方案。
对于当场难以解决的问题,由主持人决定“是否有必要继续讨论”或者“另定时间再讨论”。
☆评审小组给出评审结论和意见,主持人签字后本次会议结束。
评审结论有三种:
(1)工作成果合格,“无需修改”或者“需要轻微修改但不必再审核”。
(2)工作成果基本合格,需要作少量的修改,之后通过审核即可。
(3)工作成果不合格,需要作比较大的修改,之后必须重新对其评审。
☆主持人和相关人员撰写《技术评审报告》(如表8-3所示)。
第三步缺陷跟踪
作者修正工作成果,消除已发现的缺陷。
评审主持人(或者指定审查员)跟踪每个缺陷的状态。
直到工作成果合格为止。
表8-3技术评审报告
XXX技术评审报告
1.基本信息
成果介绍
名称,版本,作者,时间等等
评审时间
评审地点
评审人员名单
角色、职务
人员A
评审主持人
…
2.问答记录
提示:
由评审主持人或记录填写,主要记录评审过程中的疑问、答复、争论、处理意见
记录A
…
3.评审结论与意见
提示:
由评审主持人填写
评审结论
[]工作成果合格,“无需修改”或者“需要轻微修改但不必再审核”
[]工作成果基本合格,需要作少量的修改,之后通过审核即可
[]工作成果不合格,需要作比较大的修改,之后必须重新对其评审
意见建议
签字
主持人签字
4.缺陷跟踪
提示:
如果使用了缺陷跟踪软件,那么无需手工填写此表
缺陷描述
缺陷解决方案、结果
8.2.3软件测试
技术评审和软件测试的目的都是为了消除软件的缺陷,两者的主要区别是:
(1)前者无需运行软件,评审人员和作者把工作成果摆放在桌面上讨论;
(2)后者一定要运行软件来查找缺陷。
技术评审在软件测试之前执行,尤其是在需求开发和系统设计阶段。
相比而言,软件测试的工作量通常比技术评审的大,发现的缺陷也更多。
软件测试的主要工作有:
☆制定测试计划
☆设计测试用例
☆执行测试
☆缺陷跟踪
☆消除缺陷
8.2.4质量保证
QA:
QualityAssurance
质量保证的实质:
检查项目的“工作过程和工作成果”是否符合既定的规范。
符合规范的工作成果不见得就是高质量的,但是明显不符合规范的工作成果十有八九是质量不合格的。
质量保证的要点:
找出明显不符合规范的工作过程和工作成果,及时指导开发人员纠正问题,切勿吹毛求疵或者在无关痛痒的地方查来查去。
在制定《质量计划》的时候,质量人员确定主要检查项和检查时间(或频度)。
质量人员在执行质量保证工作的时候,如果发现质量问题,应该立即记录下来。
最好使用问题跟踪工具(或者缺陷跟踪工具),有助于提高工作效率。
质量人员首先设法在项目内部解决已经发现的质量问题,与项目成员协商,给出解决措施。
在项目内难以解决的质量问题,由上级领导给出解决措施。
质量人员定期撰写《质量保证报告》(格式见表8-4),向项目成员和上级领导汇报现阶段的质量状况。
表8-4质量保证报告
质量保证报告
项目名称
报告日期
质量保证员
报告批次
过程质量检查
受检查的过程域
检查结果
产品质量检查
受检查的工作成果
检查结果
问题与对策,经验总结:
从问题跟踪工具中提取问题的信息
8.2.5缺陷跟踪与问题跟踪
(1)缺陷
人们在执行技术评审、软件测试、质量保证工作时,会发现不少软件缺陷(或者其它质量问题)。
缺陷的属性如表8-5所示。
表8-5缺陷的属性
缺陷属性
描述
缺陷编号
给每个缺陷分配唯一的ID
缺陷类型
给缺陷划分一些类型,便于统计
所属模块
说明该缺陷所属的模块
缺陷状态
常用缺陷状态有:
新缺陷、缺陷再现、解决待关闭、关闭等
缺陷描述
用一段文字描述缺陷
附件
本缺陷的相关附件
严重性
划分缺陷的严重性:
严重、中等、轻微
优先级
划分处理缺陷的优先级:
高、中、低
报告者
报告缺陷的人
报告日期
给出本缺陷的报告日期
接受者
处理缺陷的人
解决方案
描述该缺陷的解决方案
更新日期
缺陷信息的更新日期
(2)缺陷跟踪工具
缺陷跟踪工具:
帮助项目成员记录和跟踪缺陷用的软件。
一般都有数据支持,可以在局域网内运行。
如果没有缺陷跟踪工具的话,人们只好用纸张或文件去记录缺陷,不仅变更缺陷信息很麻烦,而且难以共享信息。
表8-5缺陷跟踪工具的常见功能
功能
描述
查询缺陷
根据缺陷类型、状态、优先级、报告者、报告日期等条件查询
添加缺陷
添加新的缺陷
修改缺陷
修改缺陷的信息
删除
删除缺陷
缺陷饼图
绘制缺陷的饼图
缺陷趋势图
绘制缺陷的趋势图
自动消息
如果缺陷信息发生变动(添加和修改),那么自动发消息给报告者和接受者
(3)问题跟踪
问题跟踪缺陷跟踪很相似,“问题”的含义比“缺陷”更加广泛。
8.3常见问题解答和实施建议
8.3.1什么是软件的质量属性和质量要素
软件质量是许多质量属性的综合体现,各种质量属性反映了软件质量的方方面面。
人们通过改善软件的各种质量属性,从而提高软件的整体质量(否则无从下手)。
(1)质量属性
常见的质量属性有:
正确性、健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等。
(2)质量要素
软件质量要素是指:
A.从技术角度讲,对软件整体质量影响最大的那些质量属性才是质量要素;
B.从商业角度讲,客户最关心的、能成为卖点的质量属性才是质量要素。
对于一个特定的软件而言,我们首先判断什么是质量要素,才能给出提高质量的具体措施,而不是一股脑地想把所有的质量属性都做好,否则不仅做不好,还可以能得不偿失。
如果某些质量属性并不能产生显著的经济效益,我们可以忽略它们,把精力用在对经济效益贡献最大的质量要素上。
简而言之,只有质量要素才值得开发人员下功夫去改善。
8.3.2企业追求什么样的质量目标
企业的根本目标是为了获取尽可能多的利润,而不是生产完美无缺的产品。
如果企业销售出去的软件的质量比较差,轻则挨骂,重则被退货甚至索赔,因此为了提高用户对产品的满意度,企业必须提高产品的质量。
但是企业不可能为了追求完美的质量而不惜一切代价,当企业为提高质量所付出的代价超过销售利益时,这个产品已经没有商业价值了,还不如不开发。
企业必须权衡质量、效率和成本,产品质量太低了或者太高了,都不利于企业获取利润。
企业理想的质量目标:
不是“零缺陷”,而是恰好让广大用户满意,并且将提高质量所付出的代价控制在预算之内。
8.3.3谁对质量负责
谁对软件质量负责?
全员负责。
任何与软件开发、管理工作相关的人员都对质量产生影响,都要对质量负责。
不要把质量问题全部推给质量人员或测试人员。
谁对软件质量负最大的责任?
谁的权力越大,他所负的质量责任就越大。
质量人员是成天与质量打交道的人,但他个人并不对产品质量产生最大的影响,所以不负最大的责任。
8.3.4为什么质量保证并不能保证质量
质量保证活动就是检查项目的“工作过程和工作成果”是否符合既定的规范。
如果质量人员发现某些项目的“工作过程以及工作成果”不符合既定的规范,那么马上可以断定产品存在缺陷。
但是符合既定规范的东西并不意味着质量一定合格,仅靠规范无法识别出产品中可能存在的大量缺陷。
不少机构的质量人员老是对照规范,查找错别字、标点符号、排版格式等问题,迷失了方向,这样只有疲劳没有功劳,而且让开发人员很厌烦。
质量保证的技术含量比较低,只能检查出肤浅的缺陷,不能对付有技术难度的缺陷。
所以单独的“质量保证”,其实不能“保证质量”。
质量保证对于保证质量而言只是必要的手段,而不是充分的手段。
对于软件质量管理而言,软件测试、技术评审比质量保证更加重要。
8.3.5为什么技术评审的效果不明显
有些机构按照CMM的要求制定了技术评审的规范,项目人员依据规范执行了技术评审(例如设计评审),但是感觉技术评审对开发工作几乎没有帮助,倒是评审会议浪费了不少精力。
为什么?
技术评审的价值在于“请同行专家评审工作成果,找出缺陷,给出改进建议”,而不在于是否按照规范召开了评审会议(形式是次要的)。
技术评审和设计评审通常是最重要的评审,项目经理一定要请真正内行的人参与评审,而且要让评审者投入一定的精力,这样才可能取得评审的效果。
习题:
软件质量管理的关键活动有哪些?
说明各项活动的主要工作。