第9章 软件质量管理Word下载.docx
- 文档编号:16675909
- 上传时间:2022-11-25
- 格式:DOCX
- 页数:22
- 大小:63.41KB
第9章 软件质量管理Word下载.docx
《第9章 软件质量管理Word下载.docx》由会员分享,可在线阅读,更多相关《第9章 软件质量管理Word下载.docx(22页珍藏版)》请在冰豆网上搜索。
CMM对质量的定义是:
①一个系统、组件或过程符合特定需求的程度;
②一个系统、组件或过程符合客户或用户的要求或期望的程度。
上述定义很抽象,人们看了准会一脸迷惘。
就让我们用“人的健康”来类比解释软件质量吧。
古时候人们以为长得结实、饭量大就是健康,这显然是不科学的。
现代人总是通过考察多方面的生理因素来判断是否健康,如测量身高、体重、心跳、血压、血液、体温等。
如果上述因素都合格,那么表明这人是健康的。
如果某个因素不合格,则表明此人在某个方面不健康,医生会对症下药。
通过类比,我们这样理解软件质量:
软件质量是许多质量属性的综合体现,各种质量属性反映了软件质量的方方面面。
人们通过改善软件的各种质量属性,从而提高软件的整体质量(否则无从下手)。
软件的质量属性很多,如正确性、精确性,健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等。
表9-1是常见质量属性的描述,先让读者对软件质量属性有个初步的了解。
质量属性
描述
正确性
正确性是指软件按照需求正确执行任务的能力。
“正确性”的语义涵盖了“精确性”。
正确性无疑是第一重要的软件质量属性。
健壮性
健壮性是指在异常情况下,软件能够正常运行的能力。
正确性与健壮性的区别是:
前者描述软件在需求范围之内的行为,而后者描述软件在需求范围之外的行为。
健壮性有两层含义:
一是容错能力,二是恢复能力。
可靠性
可靠性是一个与时间相关的属性,指的是在一定环境下,在一定的时间段内,程序不出现故障的概率,因此是一个统计量,通常用平均无故障时间来衡量。
软件可靠性问题通常是由于设计中没有料到的异常和测试中没有暴露的代码缺陷引起的。
性能
性能通常是指软件的“时间—空间”效率,而不仅是指软件的运行速度。
人们总希望软件的运行速度高些,并且占用资源少些。
易用性
易用性是指用户使用软件的容易程度。
软件的易用性要让用户来评价。
清晰性
清晰意味着工作成果易读、易理解,开发人员只有在自己思路清晰的时候才可能写出让别人易读、易理解的程序和文档。
安全性
安全性是指防止系统被非法入侵的能力,既属于技术问题又属于管理问题。
一般地,如果黑客为非法入侵花费的代价(考虑时间、费用、风险等因素)高于得到的好处,那么这样的系统就可以认为是安全的。
可扩展性
可扩展性反映了软件适应“变化”的能力。
在软件开发过程中,“变化”是司空见惯的事情,如需求、设计的变化,算法的改进、程序的变化等。
可扩展性是系统设计阶段重点考虑的质量属性。
兼容性
兼容性是指两个或两个以上的软件相互交换信息的能力。
兼容性的商业规则是:
弱者设法与强者兼容,否则无容身之地;
强者应当避免被兼容,否则市场将被瓜分。
可移植性
软件的可移植性指的是软件不经修改或稍加修改就可以运行于不同软硬件环境(CPU、OS和编译器)的能力,主要体现为代码的可移植性。
表9-1常见质量属性的描述
什么是软件质量要素?
它是指:
(1)从技术角度讲,对软件整体质量影响最大的那些质量属性才是质量要素;
(2)从商业角度讲,客户最关心的、能成为卖点的质量属性才是质量要素。
对于一个特定的软件而言,我们首先判断什么是质量要素,才能给出提高质量的具体措施,而不是一股脑地想把所有的质量属性都做好,否则不仅做不好,还可能得不偿失。
如果某些质量属性并不能产生显著的经济效益,我们可以忽略它们,把精力用在对经济效益贡献最大的质量要素上。
简而言之,只有质量要素才值得开发人员下功夫去改善。
9.2商业目标决定质量目标
大凡软件工程教科书为了强调质量的重要性,总是要举一些历史上发生过的重大软件质量事故,例如航天飞机爆炸、核电站失事、爱国者导弹发生故障等等。
这些事故的确不是危言耸听,给人们敲响了质量的警钟。
学术界总是喜欢宣扬质量至上的理念,而忽视企业的商业利益,将质量目标凌驾于商业目标之上。
我不能评判这种现象是好还是坏,但是的确误导了大量读者。
许多软件人员都有“质量越高越好”的观念,这是被教科书灌输的,而不是他自己领悟出来的。
质量的最高境界是什么?
是尽善尽美,即“零缺陷”。
我曾在著作《高质量程序设计指南——C++/C语言》中大肆宣扬了高质量程序设计的理念,力求使C++程序达到“零缺陷”的质量目标。
尽管此书得到了许多程序员的赞同,但是我经过反思之后改变了质量观念,我要着重指出的是:
重视软件质量是应该的,但是“质量越高越好”并不是普适的真理。
只有极少数软件应该追求“零缺陷”,对绝大多数软件而言,商业目标决定了质量目标,而不该把质量目标凌驾于商业目标之上。
航空航天等系统对质量要求极高,任何缺陷都有可能导致机毁人亡,所以人们不惜一切代价去消除缺陷。
在发射航天器之前,只要发现任何异常,就会立即取消发射指令,直到异常被消除为止。
前苏联做得最过分,许多重大武器系统的负责人都签了生死状,系统研制成功则获得英雄勋章,失败则被枪毙。
在这种压力下没有人敢对质量有一丝松懈。
上述严格系统毕竟是少数,绝大多数普通软件的缺陷并不会造成机毁人亡这样的重大损失,否则没有人敢从事软件开发了。
在日常工作中,我们接触过的软件几乎都是有缺陷的,即便是软件业老大Microsoft,它的软件产品也经常出错甚至导致死机,人们骂几句后还会照样使用有缺陷的软件。
企业的根本目标是为了获取尽可能多的利润,而不是生产完美无缺的产品。
如果企业销售出去的软件的质量比较差,轻则挨骂,重则被退货甚至被索赔,因此为了提高用户对产品的满意度,企业必须提高产品的质量。
但是企业不可能为了追求完美的质量而不惜一切代价,当企业为提高质量所付出的代价超过销售收益时,这个产品已经没有商业价值了,还不如不开发。
企业必须权衡质量、效率和成本,产品质量太低了或者太高了,都不利于企业获取利润。
企业理想的质量目标不是“零缺陷”,而是恰好让广大用户满意,并且将提高质量所付出的代价控制在预算之内。
9.3质量保证能够保证质量吗
质量保证(QualityAssurance,QA)是CMM和ISO9001最为推崇的改善软件质量的方法。
基于我亲身实践和调查研究,我敢冒天下之大不讳说一句:
质量保证并不能保证质量,它是个美丽的谎言。
CMM对软件质量保证是这样描述的:
软件质量保证的目的是为管理者提供有关软件过程和产品的适当的可视性。
它包括评审和审核软件产品及其活动,以验证其是否遵守既定的规程和标准,并向有关负责人汇报评审和审核的结果。
简而言之,质量保证活动就是检查软件项目的“工作过程和工作成果”是否符合既定的规范。
如此简单的活动为什么被冠以“质量保证”这等份量的术语呢?
没有历史典故,经我考究,猜想是源于一个天真的假设:
过程质量与产品质量存在某种程度的因果关系,通常“好的过程”产生“好的产品”,而“差的过程”将产生“差的产品”。
假设企业已经制定了软件过程规范,如果质量保证人员发现某些项目的“工作过程以及工作成果”不符合既定的规范,那么马上可以断定产品存在缺陷。
反之,如果质量保证人员没有发现不符合既定规范的东西,那么也可以断定产品是合格的。
基于上述假设,质量保证人员即使不是技术专家,他也能够客观地检查和监控产品的质量。
这是质量保证方法吸引人的一面。
但是符合既定规范的东西并不意味着质量一定合格,仅靠规范无法识别出产品中可能存在的大量缺陷。
例如,即使程序员们都按照统一的编程规范来编写程序,但是编程新手的代码可能错误百出,而高手的代码则无可挑剔,可是质量保证这种方法根本无法识别新手和高手的差距。
质量保证的技术含量太低了,只能检查出肤浅的缺陷,不能对付有技术难度的缺陷。
所以单独的“质量保证”其实并不能“保证质量”。
有个软件公司过了CMM3级,其质量保证人员给我发了一个email:
我很迷茫,很想找一个人聊聊,希望你能给我点主意,化解我心中的谜团。
昨天我们公司拿到了CMM3的证书,但是我一点都高兴不起来。
公司宣称,我们的软件质量大大提高了,但是我却没有信心。
我们的过程执行得很好,但是我觉得并没有在很大程度上改善产品的质量。
今天还有一个项目经理跟我诉苦:
前一阶段大家都忙于执行过程,但是他的产品质量令人很不满意,尤其是测试做的很不到位。
我是这个项目的SQA,所以我很理解他,但是我帮不上他的忙。
因为他们的过程执行得很好,这个项目可是通过CMM3级正式评估了的。
当然,执行CMM有不少好处,比如文档全面完整了,项目管理的可视性提高了。
但是对于我们公司而言,它并没有在根本上提高我们公司的软件能力。
比如概要设计,开发人员根本就不知道用来干吗的,怎么能指望他们写出高质量的概要设计说明书出来。
而在做技术评审的时候,他们很少能找出逻辑性的错误,只能发现一些诸如错别字之类的小错误。
我们几乎每一个配置项都要经过评审,但是大部分评审都只能发现一些无关痛痒的问题。
公司已经通过CMM3级了,我认为过程执行得很好了,可是软件质量仍然比较差。
这是怎么回事啊,你觉得原因在哪里?
这个email很有代表性,它反映了一个共性问题:
公司按照CMM3级的要求执行,而且质量人员也认为执行过程符合既定的规范,但是软件产品的质量仍然低下。
所以我说“质量保证并不能保证质量”,这句话一点都不过分。
质量保证对于保证质量而言只是必要的手段,而不是充分的手段。
质量保证这个术语名不副实,含义模糊,我强烈建议将“质量保证”改名为“过程检查”,免得误导国内企业。
那么怎么才能保证软件的质量呢?
请阅读本章第5节“全面软件质量管理”。
9.4质量人员的状况
9.4.1郁闷的质量人员
由于工作关系,我和不少软件机构的质量人员打过交道。
我觉得有必要反映一下质量人员的状况,给他们一些声援。
接上个email,那位质量人员继续向我诉说:
我现在觉得很郁闷,CMM评估前还有目标,评估完了冷静下来却觉得效果很差,很没劲。
项目经理向我诉苦,他们过程执行的很好,但是对产品质量很不满意,我却无能为力,我这个QA还有什么用处啊!
所以我现在干活没有动力,因为不能产生效益,做再多的工作也觉得是白干。
而且我现在手头有5个项目要跟踪,还不包括一些整理培训记录的杂活,我觉得自己连工人也不如。
我有一些很好的想法却无处发挥,所以我很迷茫,很矛盾地考虑去留问题。
类似的email我大概收到十来个。
在汉语字典里找不到“郁闷”这个词,它是现代人发明的。
郁闷的滋味各色各样,只有正在郁闷的人感受最真切。
我发现在软件职业里,质量人员是最郁闷的一族。
郁闷的共同特征有:
(1)在执行质量保证活动时,经常受别人的气,真是吃力不讨好。
(2)如果项目取得成功,主要功劳都被项目主管霸占了,领导们至多会给质量人员一些口头上的感谢。
领导们嘴上重视产品的质量,但是内心并不重视质量人员。
(3)质量人员没有实质性的权力,没有成就感,但是却对质量负有最多的责任。
(4)待遇一般,看不到升迁的机会,没有盼头,要么成为打杂的,要么另寻出路。
在企业里,职位是有高低之分的,但是人人都是平等的。
郁闷的滋味是很不好受的,为啥老是让质量人员郁闷呢,这显然很不公平。
我曾经做过伤害质量人员的事情,现在良心发现,在这里道个歉,并声援他们。
两年前,我在一个软件事业部负责推广软件工程和CMM。
公司领导比较重视,给我6个全职人员,有充足的资金,声势浩大,那时我比较自负,很少采用协商的方式解决纠纷。
公司有专门的质量部门,定期到各事业部检查质量。
由于我们事业部采用的是CMM,而质量部门采用的是ISO9000标准,我不懂他的,他不懂我的,所以产生了纠纷。
事业部的各级领导都有销售压力,用他们的话说是:
没有时间陪质量部门的人“玩”,大家都有“对付”而不是“配合”质量部门的心态。
有一次质量部门要检查某个重点项目的文档,偏偏这个项目是保密的,一方要检查一方要保密,双方弄僵了。
在事业部内部开会的时候,这个重点项目的负责人大发脾气说:
我最烦那些人,看么看不懂,还老是来检查,别说项目是保密的,就是不保密的我也不给看。
大家火得很热烈,我就火上加油给质量部门发了email,大致意思是“你们搞ISO9000的人不懂软件工程,不懂CMM,不懂得软件开发却老是来检查软件项目,对本事业部只有干扰而没有帮助”,email言词激烈。
我把email发给一位和我打交道比较多的质量部人员,并抄送给本事业部所有人员,给本部门大大地出了一口气。
过了几天,我收到质量部同事的email,足足有两页纸。
有几句话我记忆很深刻:
收到你的email时我十分震惊。
依你的身份,当着事业部百余名员工的面,把工作上的怨气发在我这个无辜的人的头上,我实在难以接受。
提高产品质量是我们的工作职责,我们并不想和任何人争吵。
观念的差异可以通过交流、协商的方式来解决,我不强求你接受任何东西,但真心希望能对你有所触动,并欢迎你和我或我的同事继续探讨、交流。
我非常后悔,因为我伤害了一个十分友善而且敬业的质量部同事。
而更糟糕的是,我这个例子只不过是冰山一角而已。
我所认识的公司内外的质量人员都是性格温和、细致耐心的人,他们的优点在于人格而不是技术。
平心而论,他们比技术出色但是情商不高的技术人员更值得交朋友。
质量检查是他们的工作职责,谁也不会有意干扰项目,所以任何人都不应该向他们发火。
9.4.2路在何方
我的一位同事在干了5年的质量保证工作后,终于厌倦了,到某大学软件学院当老师去了,目前看上去比较满意。
有一位生物专业毕业的、做了多年ISO9000的同事和我谈心,她也说很想当大学老师,当然不教质量管理的课程,而是希望重拾她的生物专业。
那位平白无故受我怨气的质量部同事正在读MBA,学得很好,我想她必定有更好的追求。
上节email的作者一边上班一边读工程硕士,她的工作任务有一些变动:
我已经转做测试了,主要原因有以下几个:
1、我们的过程质量虽然很好,但是在提高产品质量方面没有达到期望的效果;
2、测试是保证产品质量的一种重要手段,我要接触一下,从而对产品的质量有更好的理解;
3、这段时间项目不多,我比较空闲,而且只做SQA的工作,有点枯燥;
4、我们公司的测试力量比较薄弱,我希望能帮忙做点什么;
5、长期以来,没有深入项目的感觉,我希望自己能够亲身去执行我们的过程,看看能不能找出点问题;
同时,我也没有放弃SQA的工作,以后在做测试的同时,我会至少兼做一个项目的SQA。
我想这样是一个相辅相成的过程。
我希望自己能对提高软件产品质量做点贡献。
你看了email就知道她是一位积极上进的好员工,她靠自己的悟性在摸索解决问题的方法。
她碰到的问题我看得很清楚,绝非个别现象。
问题的根源是:
她公司的领导不懂得真正有效的质量管理,使她无法发挥全职质量人员的价值。
软件行业里的人嘴上都说质量很重要,可是大多数企业并没有给质量人员提供良好的职业发展空间。
质量人员通常仅给企业起到心里安慰的作用。
这样下去,有能耐的质量人员会跑光的。
在大多数的软件企业里,男性处于支配地位,女性职位相对比较低。
而质量人员通常是女性,很多男性主管从未真正地把质量人员当成企业的宝贵人才看待,这种偏见是非常有害的。
任何素质合格的员工都是宝贵的人才,很多默默无闻的人才其实是被不懂得管理的领导给荒废了。
质量人员之所以没有发挥预期的效果,不是性别缘故,主要过失在于领导者。
企业领导们要好好反省,你自己不懂质量管理,不是瞎指挥吗?
我的建议如下:
(1)无论是企业领导还是质量人员,都要好好学习全面软件质量管理方法,结合企业的特点给出真正有效的质量管理方案。
(2)只有当企业领导采用了正确的质量管理方案,用了合格的质量人员,才可能看得到比较明显的质量改善,才能形成良性循环。
(3)如果想让质量人员负起比较重的责任,那么就要给她相应的权力。
在企业中,责任和权利是成正比的。
如果质量人员的地位无足轻重,那么必然导致质量管理无足轻重。
(4)给质量人员一个适宜的升迁机会和薪资待遇,让她能够快乐地工作,而不是成天无奈地检查质量。
9.4.3赞美诗
在我写这本书的时候,中国正遭受非典型肺炎(SARS)的肆虐。
人们在危难之际想起了医护人员的好处,因此涌现了许多对医护人员的赞美诗。
我碰巧在网上搜索到一位软件诗人献给质量人员的赞美诗“晚上八九点钟的太阳”,我看了不禁喜悦和感动。
我认为没有必要等到软件质量灾难降临的时候才想起质量人员,于是摘录这首诗公布于此。
诗中的“狼人”和“银弹”是软件工程的典故,寓意深刻。
衷心感谢这位不知姓名的浪漫软件诗人。
晚上八九点钟的太阳
——献给软件测试和质保人员
我更喜爱晚上八九点钟的太阳,
虽然人们都已把他遗忘,
但他还是艰难地悬挂在天上。
因为他将奏出黎明的交响。
没有他
又怎会呼唤出一片明亮?
因为他会化成早上的朝阳。
又怎会有什么希望?
因为他是上帝的臂膀。
没有他,
又怎会创造万物的光芒。
狼人望月嚎叫,
它知道
月亮映出的太阳之光,
终将化为银弹,
射入它的胸膛。
我
更喜爱
晚上八九点种的太阳。
9.5全面软件质量管理
9.5.1模型
如果一个人浑身上下都没有毛病,那么他就很健康;
反之如果浑身是病,那么就不健康。
所以毛病是健康的死对头。
同理,质量的死对头是缺陷,缺陷是混在产品中的人们不喜欢、不想要的东西,它对产品没有好处只有坏处。
人们常说的Bug就是缺陷的形象比喻。
显然,缺陷越多质量越低,缺陷越少质量越高,提高软件质量的基本手段是消除软件缺陷。
让我们看看中国郎中治病的故事,受点启发。
在中国古代,有一家三兄弟全是郎中。
其中有一人是名医,人们问他:
“你们兄弟三人谁的医术最高?
”
他回答说:
“我常用猛药给病危者医治,偶尔有些病危者被我救活,于是我的医术远近闻名并成了名医。
我二哥通常在人们刚刚生病的时候马上就治愈他们,临近村庄的人说他是好郎中。
我大哥不外出治病,他深知人们生病的原因,所以能够预防家里人生病,他的医术只有我们家里才知道。
上述故事里,郎中三兄弟是三种治病方式的代言人。
相似地,提高软件质量也有三种方式。
老大治病的方式最高明,如果人们能够预防生病的话,那么没病就用不着看医生了。
提高软件质量最好的办法是:
在开发过程中有效地防止工作成果产生缺陷,将高质量内建于开发过程之中。
主要措施是“不断地提高技术水平,不断地提高规范化水平”,其实就是练内功,通称为“软件过程改进”。
即使一个人严守养生之道,身体状况良好,但总是会意外地得病的,得了病就要去看医生。
老二治病的方式就是医院的模式,病人越早看病,就越早治好,治病的代价就越低。
同理,在开发软件的时候,即使人们的技术水平很高,并且严格遵守规范,但是人非机器,总是会犯错误的,因此无法完全避免软件中的缺陷。
那么怎么办呢?
当工作成果刚刚产生时马上进行质量检查,及时找出并消除工作成果中的缺陷。
这种方式效果比较好,人们一般都能学会。
最常用的方法是技术评审、软件测试和过程检查,已经被企业广泛采用并取得了成效。
老三治病的方式代价最高,只能是不得已而为之。
可在现实之中,大多数软件企业采用老三的方式来对付质量问题。
典型现象是:
在软件交付之前,没有及时消除缺陷。
当软件交付给用户后,用着用着就出错了,赶紧请开发者来补救。
可笑的是,当软件系统在用户那里出故障了,那些现场补救成功的人倒成了英雄,好心用户甚至还寄来感谢信。
借鉴老大、老二治病的方法,我们提炼出全面软件质量管理的模型,如图9-1所示。
项目中的所有人员几乎都参与了质量活动,只是介入的程度不同而已,本章后面几节将逐一介绍这些质量活动。
软件过程改进:
提高软件技术水平和规范化水平
软件项目X
软件测试
过程检查
技术评审
制定质量计划
图9-1全面软件质量管理的模型
9.5.2质量人员的职责
谁对软件质量负责?
是全员负责。
任何与软件开发、管理工作相关的人员都对质量产生影响,都要对质量负责。
所以人们不要把质量问题全部推出质量人员或测试人员。
谁对软件质量负最大的责任?
谁的权利越大,他所负的质量责任就越大。
质量人员是成天与质量打交道的人,但他个人并不对产品质量产生最大的影响,所以也不负最大的责任。
前面分析过了,如果质量人员仅仅从事质量保证活动的话,那么他对软件开发和管理的介入就非常肤浅,对提高质量缺乏实质性贡献,最终导致他很“郁闷”。
在图9-1的模型中,质量人员的主要职责是:
✧负责制定质量计划(很重要但是工作量比较少);
✧负责过程检查(类似于CMM中的质量保证),约占个人工作量的20%;
✧参与技术评审,约占个人工作量的30%;
✧参与软件测试,约占个人工作量的30%;
✧参与软件过程改进(面向整个机构),约占个人工作量的20%;
上述工作量的比例仅供参考,在实际应用时必须根据项目的特征而定。
技术评审与软件测试关注的是产品质量而不是过程质量,两者的技术强度比过程检查要高得多,更加容易发现缺陷。
技术评审和软件测试能弥补过程检查的不足,我们不能将过程检查、技术评审和软件测试的观念混为一谈,但是也不能把三者孤立起来。
质量人员除了过程检查之外,还要参加(并监督)重要的技术评审和测试工作,这样做才富有成效。
软件过程改进是面向整个机构的,而不仅仅是针对某个项目的。
由于质量人员的日常工作主要是过程检查、技术评审、软件测试,成天与质量问题打交道,所以他能发现整个机构的共性质量问题,因此质量人员参与软件过程改进是很有意义的。
软件过程改进一般由SEPG(SoftwareEngineeringProcessGroup)负责。
我曾经和不少CMM咨询师和SEPG的负责人交流过,多数人认为SEPG是“立法机构”,质量小组是“执法机构”,两者应该彻底分开。
我认为这种设想很不适合中国中小型软件机构(100人以下),企业又不是国家政法机构,哪有那么多的人和钱去搞理想主义啊!
图9-1的模型完全出于实用主义,所以不受ISO9000和CMM的约束。
9.5.3制定质量计划
质量计划就是为了实现质量目标的计划。
而质量
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 第9章 软件质量管理 软件 质量管理