如何提高软件质量

合集下载
相关主题
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
过程。
已定义级
要求制定企业范围的 工程化标准,并将这 些标准集成到企业软 件开发标准过程中去。 所有开发的项目需根 据这个标准过程裁剪 出与项目适宜的过程, 并且按照过程执行。 过程的裁剪不是随意 的,在使用前必须经 过企业有关人员的批
准。
CMM 级别与软件质量关系表格
每千行软件 的缺陷数 目
大于 10
软件
硬件
虚拟、动态
固化、稳定
不确定性Fra Baidu bibliotek
相对清楚
非常困难
正常
逻辑性强
流水线、工序
复杂
清楚
复杂
多数简单、适中
复杂、新的需求、多数简单、适中、 可以不断打补丁 没有新的需求
软硬件开发过程的比较
软件
54-56%质量缺陷来自需 求不清楚 25%质量缺陷来自设计和 编程
这里不是软件质量管理的 主要阶段 不仅支持原有功能,解 决以前就存在的问题, 而且增加新特性、加强 新功能
代码大全怎么说
内部质量特征包括: +可维护性。修改一个软件系统,提高其性能或修正其错误 的能力。 +灵活性。修改系统使其能适应于不同的用途或环境的能力, 而不必对系统进行特定的设计。 +可移植性。能修改所设计的某一系统使其能在其它环境下 运行的能力。 +可重用性。能将系统的一部分用于其它系统的难易程度。 +可读性。能读懂或理解系统源代码的能力,尤其是在细节 说明这一级上。 +可测试性。对整个系统进行单元或系统测试以证实其满足 所有需求性能的测试难易程度。 +可理解性。能从整个系统水平或细节说明这一级上理解整 个系统的难易程度。可理解性要比可读性从更一般的水平上 讨论系统的紧密性。
▪ ISO 关于质量的定义表示如下:
“ 一个实体(产品或服务)的所有特性,基于这些特性可以满足明显 的或隐含的需要。 ”
什么是软件质量?
✓外部用户要求:正确,高效,健壮,易用和可靠 ✓内部维护人员要求:可维护(代码易读,易读,
易Debug,注释清晰,容易扩展) ✓内部测试人员要求:可测试,易用,易理解 ✓企业产品化要求:可扩展,可移植,可配置,灵活,
▪ 1986年3月到1987年1月,由加拿大原子能有限公 司生产的Therac 25 放射治疗机 造 成 两人死亡、 数人受伤。
软件质量的过去
▪ 1992年,法国伦教由于救护派遗系统全部崩溃,导 致多名病人因为抢救不及时而失去生命。
▪ 1991 年海湾战争期间,美国爱国者导弹由于软件计 时系统累计误差造成拦截失败 ,造 成人员无辜伤 亡。
小于 0.01
优化级
降低开发时 10Z 间到 1/4
<=2
近似完全可靠
改进我们的软件质量吧
实施简洁的开发过程体系
根据不同业务特点可以选择瀑布模型, 迭代模型等,并在这些模型上进行适当 的变化以适应于短平快的产品开发特点
管理方面经验。 (3) 实施工程:实施软件开发 和验证;
(4) 客户评估:评价开发工作, 提出修正建议,制定下一步计 划。
RUP ( Rational Unified Process )
RUP 工作流程示意图
IPD ( Integrated Product Development )
IPD 流程示意图
重用性高,模块和组件化
代码大全怎么说
因此《代码大全》将软件质量特征分为内部质量特征和外部质量特征:
外部质量特征包括: +正确性。整个系统受说明、设计和实现的错误影响程度。 +可用性。用户学会和使用系统的难易程度。 +效率。对系统资源的最小利用,包括存储和执行时间。 +可靠性。在一定条件下执行特定功能的能力。 +完整性。防止非法或不适当地访问。完整性思想包括:限制非 法用户访问,同时确保证数据恰当访问;并行数据表进行并行修 改;数据段仅含有有效数据等等。 +适应性。系统在应用或其它环境下不作修改就能使用的能力。 +精确性。系统不受错误影响的程度,尤其是数据输出方面。精 确性和正确性是不同的。精确性是对系统完成其工作性能良好的 衡量,而不是它设计得是否正确。 +坚固性。系统对无效输入或压力环境中能继续执行其功能的能 力。
大主要来源包括草率的需求定制和象征性的案例设计和开发。

3、大约80%的缺陷来自20%的模块,而约半数的模块
是几乎没有缺陷。

4、90%的软件的停工期最多来自于10%的缺陷。
总结一下
▪ 上面四条原则说明了两个问题, ▪ 一是错误越早发现成本越低,而且大部分的
错误都是在软件开发的前面阶段引入的。 ▪ 二是大部分的错误都集中在少数的模块。
▪ 项目没有被很好地理解;计划不周, 最终导致进度拖延。
▪ 没有充分的文档资料。 ▪ 人与人的交流比写程序困难得多。 ▪ 软件可靠性缺少度量的标准,质量
无法保证。 ▪ 软件难以维护、不易升级,问题越
改越多。
如何改进我们的软件质量的思考
▪ 从一个企业的长远发展来看,首先应当从流 程抓起,规范软件产品的开发过程。这是一 个软件企业从小作坊的生产方式向集成化、 规范化的大公司迈进的必经之路,也是从根 本上解决质量问题,提高工作效率的一个关 键手段。
接受的。但这的确是个事实。 记得有个做了将近 30 多年 的需求分析专家说过:即使 是一个已经达到 CMM4 级 的公司,也完全有可能做不
好需求分析。为什么?技术,
技术是成功的另外一个必要 条件
总之流程很关键,技术 也很重要,我的观点是: 鱼和熊掌,两者都不能
放。
我们的遇到的问题
▪ 对于软件开发来说,要保证软件的质量,需要掌握多方面的 技术,包括
CMM的五个等级
▪ 在 CMM 中,把软件工厂分为五个等级: ▪ 初始级 ▪ 可重复级 ▪ 已定义级 ▪ 管理级 ▪ 优化级
CMM的等级说明
初始级
软件过程是未加定义 的随意过程,项目的 执行是随意甚至是混 乱的。也许,有些企 业制定了一些软件工 程规范,但若这些规 范未能覆盖基本的关 键过程要求,且执行 没有政策、资源等方 面的保证时,那么它 仍然被视为初始级。
我们把影响软件质量的因素分成三组,分别反映用户在使用软件产品时的 三种不同倾向或观点。这三种倾向是:产品运行、产品修改和产品转移。 信息系统作为一个产品,也可以参照这三种倾向来定义。
我们需要注意的几个数据

1、在项目发布后发现和修复Bug的成本是需求和设计
阶段所需的一百倍!

2、80%可避免的重复劳动源自于20%的缺陷,其中两
软件过程成 熟度等级
初始级
软件准时提 交的百分 比
<=50
每人每月生产 的程序行 数
Z
软件需要返 工的百 分比
>=45
平均软件失效 时间(近似)
2 到 60 分钟
小于 10
可重复级
90
1.5Z
20
小于 1
已定义级
99
2.5Z
10
小于 0.1
管理级
降低开发时 5 Z
5
间到 1/2
1-160 小时 不确定 不确定
▪ 分析技术 ▪ 设计技术、 ▪ 编码技术 ▪ 测试技术
在国内有一个普遍的非正常现象,就是大家觉得只有编程能 力才是玩电脑的真正技能。就好像造一套房子,其它都不重 要,只要砖瓦匠有高超的技能就行了。尽管这个比喻会打击 很多程序员的自尊心,但这的确是一个事实。我们缺少系统 级的工程师,在分析和设计方面的工作做得很不扎实。
关于测试的一些介绍
▪ 白盒测试 ▪ 黑盒测试 ▪ 单元测试 ▪ 集成测试 ▪ 系统测试
改善软件质量的技术
▪ 软件质量目标 ▪ 明确定义质量保证工作 ▪ 测试策略 ▪ 软件工程指南 ▪ 非正式技术复查(review,walk-through) ▪ 正式技术复查 ▪ 外部审查
缺陷检测率
国际上流行的质量标准 (CMM)
▪ 软件能力成熟度模型是目前国内软件企业中非常受欢迎的一 个质量标准。并且该标准已经成为业界一个事实上的标准。 CMM 为软件组织提供了一个指导性的管理框架。在这个框 架的指导下:
▪ • 软件组织可以对其软件开发、维护过程获得控制。 ▪ • 软件组织可以推进其软件工程更为科学、推进软件过程管
理更为卓越。 ▪ • CMM 通过确定当前软件过程管理的成熟度,通过标识软
需求分析 设计、编程 测试 发布 软件拷贝
维护
硬件
《=》 调研分析 《=》 设计阶段 《=》 设计审查 《=》 设计完成 《=》 制造、检验 《=》
维修
质量控制的主要阶段之一 质量控制的主要阶段之一
生产的主要过程,质量 控制的重点 支持原有功能,解决运 行中出现的问题,一般 比较容易预测
我们遇到了什么?
目前主要的一些软件开发过程模型
▪ 瀑布模型 ▪ 原型模型 ▪ 快速应用开发(RAD)模型 ▪ 螺旋模型 ▪ 喷泉模型 ▪ 增量模型和迭代模型 ▪ 构件组装模型 ▪ 并发模型
流程与技术
▪ 流程和成功不是等价的。没 有流程就成功是不可能得到
保证,但有了流程并不意味
着肯定能够成功。这恐怕是
很多迷信于流程的人所不能
我们需要做好的地方
▪ UML 代表软件建模的发展趋势 ▪ 需求分析的能力 ▪ 学习好《设计模式》 ▪ 测试技术 ▪ 程序员也要有扎实的文档编写能力 ▪ 良好的编程习惯
关于软件测试
▪ 软件测试是软件质量控制中的关键活动。业 界的统计数据表明,测试的成本大约占软件 开发总成本的 50 %左右。
▪ 软件测试的目的是要发现软件中的错误。一 个好的测试是发现至今没有被发现的错误。 传统的软件测试专注于动态测试范畴,如: 单元测试,集成测试和系统测试。而测试工 程的发展已经进入到了全流程的测试,包括 开发过程前期的静态测试
▪ 1990年美国电话系统中新投入使用的软件发生失效, 导致主千线远程网大规模崩溃 ,给运营商造成了重 大的经济损失。
▪ 1991年,由于一系列局域电话网因软件错误而中断, 造成了数以千计依靠电讯公司运营业务的公司遭受 巨额的资金损失。
软硬件产品的不同点
特征 存在形式 客户需求 度量性 生产过程 逻辑关系 接口 维护
瀑布模型
瀑布模型是应用的最为广泛的一种模型,也是
需求分析 最容易理解和掌握的模型,然而它的缺陷也是 显而易见的。遗漏的需求或者不断变更的需求 会使得该模型无所适从。然而,对于那些容易 设计 理解但很复杂的项目,采用瀑布模型会是比较 适合的,因为你可以按部就班的去处理复杂的 问题。在质量要求高于成本和进度要求的时候, 该模型表现的尤其突出。 编程
缺陷代价曲线
软件质量的过去
▪ 20 世 纪60年代中期,美国的首次金星探测计划, 因为在FORTRAN语言程 序 的 D O 语 句 中漏掉一 个逗号,惨遭失败。
▪ 1996年,欧洲航天局首次发射阿丽亚娜5号火箭失 败,其直接原因是火箭控制系统的软件故障,导致 直接经济损失5亿美元,还使耗资80亿美元的开 发 计 划 延迟了三年。
测试
维护
RAD模型(V模型)
螺旋模型
螺旋型项目从小的规模开(始1,) 制定计划:确定软件目标, 然后探测风险,制定风险选控定制实施方案,弄清项目开发 计划,接着确定下一步项的目限是制条件; 否还要继续,然后进行下一个 螺旋的反复。该模型的最(大2优) 风险分析:分析评估所选 点就是随着成本的增加,方风案险,考虑如何识别和消除风 程度随之降低。然而螺旋险模;型 的缺点是比较复杂,且需要管 理人员有责任心,专注以及有
可重复级
人们根据多年的经验和教训, 总结出软件开发的首要问题不 是技术问题而是管理问题。因 此,第二级的焦点集中在软件 管理过程上。一个可管理的过 程则是一个可重复的过程,可 重复的过程才能逐渐改进和成 熟。可重复级的管理过程包括 了需求管理、项目管理、质量 管理、配置管理和子合同管理 五个方面;其中项目管理过程 又分为计划过程和跟踪与监控 过程。通过实施这些过程,从 管理角度可以看到一个按计划 执行的且阶段可控的软件开发
件的质量和过程改进中关键的、要害的问题,可以指导软件 组织选择正确的软件过程改进策略。 ▪ • CMM 将其焦点,聚焦在一系列具体的软件过程活动上, 并以侵略方式( Aggressively )达到这些活动。一个软件组 织就可以稳定地、持续地改进其整个软件组织过程,使得其 软件过程管理能力取得持续地、持久地不断争长提高。
如何提高软件质量
主题
▪ 什么是软件质量? ▪ 软件质量的过去和将来! ▪ 我们遇到了什么?或者即将遇到什么? ▪ 怎么办? ▪ 参考资料
什么是质量?
▪ 质量具有三个维度:
• 符合目标。目标是客户所定义的,符合目标即判断我们是不是在做需 要做的事情。
• 符合需求。即产品是不是在做让它做的事情。 • 符合实际需求。实际的需求包括用户明确说明的和隐含的需求。
相关文档
最新文档