当前课程知识点:软件工程与软件自动化 >  第七章 软件质量保证 >  7.4 全面软件质量管理 >  授课视频

返回《软件工程与软件自动化》慕课在线视频课程列表

授课视频在线视频

下一节:专家访谈

返回《软件工程与软件自动化》慕课在线视频列表

授课视频课程教案、知识点、字幕

嗨,大家好

今天我们一起来讨论全面软件质量管理

全面软件质量管理这个词是借鉴于传统制造业中

全面质量管理而来的

是对软件质量保证的扩展和完善

首先我们来看一个问题

软件质量保证能保证软件产品的质量吗?

其实这个问题挺吓人的

因为它听起来好像很绝对的样子

一般为了谨慎起见,对于这种比较绝对的问题

我们往往习惯经过长时间的思考之后

往往会给出否定的回答

也就是单靠SQA不能保证产品的质量

为什么这么说呢?

其实从软件质量保证的定义和描述中

我们就已经明白了,软件质量保证的主要活动

就是检查软件项目的工作过程和工作成果

是否满足和符合既定的规范

如果质量保证人员没有发现不符合既定规范的东
西

那么他能不能断定这个软件产品是合格的呢?

好像他自己是无法得出这样的一个结论

也就是说,质量保证对于保证产品质量而言

只是必要的手段,而不是充分的手段

既然单靠质量保证无法完全保证产品的质量

那么还有什么因素是我们需要注意的呢?

提高软件产品(质量)最好的办法就是

在开发过程中有效地防止工作成果产生缺陷

将高质量内建于软件的开发过程之中

主要措施就是不断地提高技术水平,不断地提高
规范化水平

其实就是练内功,通称为软件过程改进

在全面软件质量管理中

要客观的评价质量保证人员的地位

不要把质量的责任全部推给质量保证人员身上

为了更清楚的认识到这一点

我们来试着回答两个问题

第一个问题是:谁对软件产品质量负责?

第二个问题是:谁对软件质量负最大的责任?

对于第一个问题而言

任何与软件开发和管理工作相关的人员

都会对产品的质量产生影响

都应该对产品质量负责

所以我们不要把质量问题全部推给

质量保证人员或者测试人员

对漫威漫画中的超级英雄们来说

对漫威漫画当中的超级英雄们来说

能力越大,责任越大

但是在现实生活中,就是权力越大,责任越大

你会认为软件质量保证人员是软件公司中权力最
大的人么?

毫无疑问,他们不是

虽然质量保证人员成天与质量打交道

但他们个人并不对产品质量产生最大的影响

也没有最大的权利

所以也不应该负最大的责任

下面我们来看一个全面软件质量管理的模型图

在这个模型图当中,首先要根据企业的情况

客户的情况和项目的情况来确定适当的质量目标

然后根据质量目标来制定质量计划

随后的开发活动就是在质量计划的指导下

以缺陷跟踪为核心,综合采用技术评审、软件测

以缺陷跟踪为核心,综合采用技术评审、软件测

和过程检查的方法

尽早尽快的对开发成果进行质量检查

及时找出并消除工作成果中的缺陷

在公司层面,经过对不同项目采用

全面质量管理活动之后,要及时的收集反馈信息

改进软件过程

提高软件开发技术水平和规范化水平

在采用全面软件质量管理模型的企业当中

质量管理人员的一个典型工作分配是这样的

一是负责制定质量计划

这部分工作虽然很重要,但是工作量比较少

二是负责过程检查,大约占个人工作量的20%

三是参与技术评审,大约占个人工作量的30%

四是参加软件测试,大约占个人工作量的30%

五是参与面向整个机构的软件过程改进

大约占个人工作量的20%

下面我们来看一看如何制定软件的质量管理计划

制定软件质量管理计划的目的就是为了更好的实
现质量目标

而质量目标则是由商业目标决定的

因此在制定质量管理计划的时候

一定要根据具体的客户需求来量身定制

切忌过分的追求高质量

我们知道,开发软件产品的最终目的是为了赚钱

所以人们为了提高软件质量所付出的代价是有上
限的

项目负责人当然希望代价越低越好

项目的质量管理计划是针对本项目进行

全面质量管理的行动纲领

那么由谁来制定质量管理计划呢?

一般是由项目的核心成员和质量人员共同协商制

主要由质量人员起草,由项目经理审批即可

质量管理计划的主要内容包括质量要素分析

质量目标,人员与职责,过程检查计划

技术评审计划,软件测试计划,缺陷跟踪工具等

技术评审的目的是尽早地发现工作成果中的缺陷

并帮助开发人员及时消除缺陷

从而有效地提高产品的质量

技术评审最初是由IBM公司为了提高软件质量

和提高程序员的生产率而倡导的

技术评审方法目前已经被业界广泛采用

并收到了很好的效果

它被普遍认为是软件开发的最佳实践之一

需要注意的是,技术评审工作可以在任何开发阶
段进行

不必等到软件运行时才来做

越早消除缺陷就越能降低开发成本

有了技术评审,开发人员能够及时地得到

同行专家的帮助和指导

无疑会加深对工作成果的理解

更好地预防缺陷

在一定程度上提高开发生产率

技术评审有两种基本类型

一是正式的技术评审,叫FTR

FTR比较严格,需要举行评审会议

参加评审会议的人也比较多

二是非正式技术评审,叫ITR

ITR的形式比较灵活,通常在开发人员之间展开

不必举行评审会议,评审人员也比较少

技术评审和软件测试的目的都是为了消除软件的
缺陷

它们之间的主要区别是

技术评审不需要运行软件

评审人员和作者把工作成果摆在桌面上进行讨论
就可以了

而软件测试一般要使用测试工具来查找缺陷

技术评审一般在软件测试之前执行

尤其是在需求阶段和系统设计阶段

相对来说,软件测试的工作量通常比技术评审的

而且发现的缺陷也比较多

在制定质量计划的时候

已经确定了项目的主要测试活动、测试时间

和测试负责人

然后再考虑软件测试的详细计划和测试用例

如果是小的软件企业,可能没有专职的测试人员

这时候开发人员可以兼职做测试工作

但一定要避免自己测自己的程序

当项目开发到了后期

过程检查和技术评审都已经没有什么意义了

开发小组急需有人来帮助他们进行软件测试

如果质量人员也能够参与进来

无论对产品的质量还是对项目的进度

都会产生强有力的提高和推动

这里需要强调的是

质量人员一定要参与软件测试

一般我们建议测试工作量可以达到个人工作总量
的30%左右

只有这样,质量人员才能深入地了解软件的质量
问题

而且给予开发小组强有力地帮助

CMM和ISO9001描述的软件质量保证

实质上就是过程检查

也就是检查软件项目的工作过程和工作成果

是否符合既定的规范

符合规范的工作成果不见得就是高质量的

但是明显不符合规范的工作成果

十有八九质量是不合格的

所以,过程检查的要点就是要找出那些明显

不符合规范的工作过程和工作成果

及时地指导开发人员纠正问题

但不要吹毛求疵或者在无关痛痒的地方查来查去

这样不但意义不大,而且还会引起开发人员的反

在制定过程检查计划的时候

质量人员重点需要确定的是主要检查项和检查时

质量人员在执行过程检查的时候

如果发现问题,应该马上记下来

过程问题也是一种缺陷

因此最好使用缺陷跟踪工具

这有助于提高过程检查的效率

质量人员应该首先想办法在项目内部

解决那些已经发现的质量问题

与项目成员们一起协商,给出解决方案

与项目成员们一起协商,给出解决方案

在项目组内难以解决的质量问题

要及时上报,由上级领导给出解决措施

对软件开发项目来说

最重要的事情之一就是跟踪和梳理

各种各样的Bug和问题,找到它们并及时解决

否则,项目就会花费更多的时间

导致整个项目的重心发生偏移

如果使用一个 Bug 和问题跟踪系统

就能够提高工作效率,加快项目进度

更好的完成任务

现在网上有很多开源的缺陷跟踪工具

大家可以免费下载使用

早期的缺陷跟踪工具仅仅是一种辅助性的工具

功能比较单一

随着敏捷开发方法的普及,出现了很多优秀的管
理工具

功能强大,超出了单纯的缺陷管理功能

比如有的工具软件可以在scrum流程的基础上

实现需求、任务、Bug、用例和Todo之间

的相互转换和轮转

比如需求可以直接分解为任务

Bug可以转换为需求

Bug可以导入到项目中作为任务跟踪

用例的执行结果可以生成Bug

Bug可以转换为用例

Bug和任务还可以转换为个人的Todo等等

因此,选择一款合适的缺陷跟踪工具

可以极大的减少无效的工作时间

提高工作效率,提升产品质量

最后,我们来讨论一个典型的软件公司

是如何从无到有设置软件质量保证岗位的案例

当一个软件公司刚刚创业的时候

大家的主要精力集中在软件开发上

项目经理都是研发出身

没有接受过系统的项目管理培训

缺少有效的管理方法指导

公司缺少系统化、制度化的研发管理流程

缺少像QA这种指导和监督机制

使得产品的计划交付时间很难准确预计,经常被
推迟

后来呢,公司增设了QA岗位

并把QA列为项目启动必需的三个人员之一

QA的岗位分为三级:QA、资深QA和QA主管

QA独立于项目组之外

为项目组提供规范流程作为产品开发的依据

指导和审核项目组是否按规范执行

要求敏锐地识别问题产生的原因

并能将经验和纠正措施固化到流程当中

实现过程改进,避免以后的项目重蹈覆辙

对于资深QA,在完成QA的工作之外

要求具备多年丰富的项目管理和质量管理经验

要根据企业的商业和业务需求

负责质量体系的架构设计

承担主要规范文件的制定和改进工作

并能够指导其他的QA和项目经理进行有效的工作

对于QA主管,则要求具备扎实的资深QA

的基本功以外,还要求跟踪和熟悉企业产品业务

能够洞察不规范和责任定义不清的管理灰色地带

以指导员和医生的角度识别和标识出问题

发现问题,它不是对比流程

不是查看实际操作与流程的不符之处

而是要找出影响质量、左右进度、降低效率、削
弱效果

进而破坏组织目标达成的不良现状来

这些现状可能包括流程问题、技术问题

工具问题、管理问题等等

针对这些问题,在流程层面,在工程方法推行方

在技术改进方面,在管理实施方面,在人员激励
方面

给出解决方案或者是能够协调各方力量

组织专题会议,推进共同改进

好,全面软件质量管理就讨论到这里,下次再见

软件工程与软件自动化课程列表:

第一章 软件工程基础

-1.1 软件工程的前生今世

--开篇阅读

--授课视频

-第一章 软件工程基础--1.1 软件工程的前生今世

-1.2 万变不离其宗

--授课视频1/3

--授课视频2/3

--授课视频3/3

-第一章 软件工程基础--1.2 万变不离其宗

-1.3 唯一不变的是变化

--授课视频1/3

--授课视频2/3

--授课视频3/3

--外部链接

-第一章 软件工程基础--1.3 唯一不变的是变化

-1.4 亡羊补牢为时不晚

--授课视频1/2

--授课视频2/2

-第一章 软件工程基础--1.4 亡羊补牢为时不晚

-扩展阅读与话题讨论

--扩展阅读

--话题讨论

第二章 敏捷开发

-2.1 方法论来源于恐惧

--授课视频

-第二章 敏捷开发--2.1 方法论来源于恐惧

-2.2 敏捷是什么

--授课视频

-第二章 敏捷开发--2.2 敏捷是什么

-2.3 典型敏捷开发方法

--SCRUM敏捷开发方法

--XP敏捷开发方法

-第二章 敏捷开发--2.3 典型敏捷开发方法

-2.4 敏捷不是万能药

--授课视频

-第二章 敏捷开发--2.4 敏捷不是万能药

-专家谈敏捷

--专家谈敏捷开发方法

-扩展阅读与话题讨论

--外部链接

--话题讨论

第三章 OO与UML

-3.1 面向对象核心概念和基本特性

--核心概念与基本特性

-第三章 OO与UML--3.1 面向对象核心概念和基本特性

-3.2 面向对象设计基本原则

--面向对象设计基本原则

-第三章 OO与UML--3.2 面向对象设计基本原则

-3.3 通用职责分配模式(GRASP)

--通用职责分配模式

-3.3 通用职责分配模式(GRASP)--作业

-3.4 从重构到模式

--模式和设计模式

-第三章 OO与UML--3.4 从重构到模式

-3.5 使用UML设计面向对象系统

--UML综述

-第三章 OO与UML--3.5 使用UML设计面向对象系统

-3.6 主要UML模型图绘制技巧

--UML用例图

--UML类图

--UML序列图绘制技巧

-第三章 OO与UML--3.6 主要UML模型图绘制技巧

-扩展阅读与话题讨论

--设计模式有毒么?

--话题讨论

第四章 对象模型分析

-4.1 案例简介

--书籍参考

--案例说明

-4.2 对象模型之一

--授课视频1/2

--授课视频2/2

-第四章 对象模型分析--4.2 对象模型之一

-4.3 对象模型之二

--授课视频1/2

--授课视频2/2

-第四章 对象模型分析--4.3 对象模型之二

-4.4 对象模型之交互

--授课视频

-第四章 对象模型分析--4.4 对象模型之交互

-扩展阅读与话题讨论

--图书推荐

--话题讨论

第五章 软件自动化技术

-5.1 软件自动化概述

--软件自动化概述

-第五章 软件自动化技术--5.1 软件自动化概述

-5.2 典型自动化方法和工具

--典型自动化工具视频

-第五章 软件自动化技术--5.2 典型自动化方法和工具

-5.3 文档自动化

--文档自动化视频

-第五章 软件自动化技术--5.3 文档自动化

-5.4 测试自动化

--测试自动化视频

--白盒测试工具VU的示例演示片段(版权属原作者)

--功能和性能自动化测试工具及简单应用演示

-第五章 软件自动化技术--5.4 测试自动化

-专家访谈

--北京理工大学刘辉教授谈软件自动化新进展

-扩展阅读与话题讨论

--各个开发阶段最流行的Java工具汇总

--话题讨论

第六章 CI/CD与DevOps

-6.1 持续集成

--持续集成视频1/2

--持续集成视频2/2

-第六章 CI/CD与DevOps--6.1 持续集成

-6.2 持续交付和部署

--持续交付和持续部署

-第六章 CI/CD与DevOps--6.2 持续交付和部署

-6.3 DevOps

--DevOps授课视频

-第六章 CI/CD与DevOps--6.3 DevOps

-专家访谈

--卓睿科技总架构师带来的精彩访谈

-扩展阅读与话题讨论

--DevOps专题

--话题讨论

第七章 软件质量保证

-7.1 质量和质量保证

--授课视频

-第七章 软件质量保证--7.1 质量和质量保证

-7.2 软件质量模型

--授课视频

-第七章 软件质量保证--7.2 软件质量模型

-7.3 SQA组织与职责

--授课视频

-第七章 软件质量保证--7.3 SQA组织与职责

-7.4 全面软件质量管理

--授课视频

-第七章 软件质量保证--7.4 全面软件质量管理

-专家访谈

--专家访谈

-扩展阅读与话题讨论

--外部链接

--话题讨论

第八章 软件过程改进

-8.1 软件过程综述

--授课视频

-第八章 软件过程改进--8.1 软件过程综述

-8.2 软件过程改进

--授课视频

-第八章 软件过程改进--8.2 软件过程改进

-8.3 能力成熟度模型

--授课视频

-第八章 软件过程改进--8.3 能力成熟度模型

-8.4 过程改进标准框架

--授课视频

-第八章 软件过程改进--8.4 过程改进标准框架

-扩展阅读与话题讨论

--敏捷和CMM矛盾么?

--话题讨论

第九章 软件复用

-9.1软件复用综述

--授课视频

-第九章 软件复用--9.1软件复用综述

-9.2 软件构件技术

--授课视频

-第九章 软件复用--9.2 软件构件技术

-9.3 软件复用实施

--授课视频

-第九章 软件复用--9.3 软件复用实施

-9.4 微服务架构

--授课视频

-第九章 软件复用--9.4 微服务架构

-扩展阅读与话题讨论

--微服务扩展

--话题讨论

文档提交处

-文档提交处--文档提交

授课视频笔记与讨论

也许你还感兴趣的课程:

© 柠檬大学-慕课导航 课程版权归原始院校所有,
本网站仅通过互联网进行慕课课程索引,不提供在线课程学习和视频,请同学们点击报名到课程提供网站进行学习。