如何提高软件质量.ppt

如何提高我们的软件质量,研发中心软件室王丁 2008-6,主题,什么是软件质量？ 软件质量的过去和将来！ 我们遇到了什么？或者即将遇到什么？ 怎么办？ 参考资料,什么是质量？,质量具有三个维度： 符合目标。目标是客户所定义的，符合目标即判断我们是不是在做需要做的事情。 符合需求。即产品是不是在做让它做的事情。 符合实际需求。实际的需求包括用户明确说明的和隐含的需求。 ISO 关于质量的定义表示如下： “ 一个实体（产品或服务）的所有特性，基于这些特性可以满足明显的或隐含的需要。 ”,什么是软件质量？,外部用户要求:正确,高效,健壮,易用和可靠 内部维护人员要求:可维护(代码易读,易读, 易Debug,注释清晰,容易扩展) 内部测试人员要求:可测试,易用,易理解 企业产品化要求:可扩展,可移植,可配置,灵活,重用性高,模块和组件化,代码大全怎么说,因此代码大全将软件质量特征分为内部质量特征和外部质量特征: 外部质量特征包括: +正确性。整个系统受说明、设计和实现的错误影响程度。 +可用性。用户学会和使用系统的难易程度。 +效率。对系统资源的最小利用，包括存储和执行时间。 +可靠性。在一定条件下执行特定功能的能力。 +完整性。防止非法或不适当地访问。完整性思想包括：限制非法用户访问，同时确保证数据恰当访问；并行数据表进行并行修改；数据段仅含有有效数据等等。 +适应性。系统在应用或其它环境下不作修改就能使用的能力。 +精确性。系统不受错误影响的程度，尤其是数据输出方面。精确性和正确性是不同的。精确性是对系统完成其工作性能良好的衡量，而不是它设计得是否正确。 +坚固性。系统对无效输入或压力环境中能继续执行其功能的能力。,代码大全怎么说,内部质量特征包括: +可维护性。修改一个软件系统，提高其性能或修正其错误的能力。 +灵活性。修改系统使其能适应于不同的用途或环境的能力，而不必对系统进行特定的设计。 +可移植性。能修改所设计的某一系统使其能在其它环境下运行的能力。 +可重用性。能将系统的一部分用于其它系统的难易程度。 +可读性。能读懂或理解系统源代码的能力，尤其是在细节说明这一级上。 +可测试性。对整个系统进行单元或系统测试以证实其满足所有需求性能的测试难易程度。 +可理解性。能从整个系统水平或细节说明这一级上理解整个系统的难易程度。可理解性要比可读性从更一般的水平上讨论系统的紧密性。,我们把影响软件质量的因素分成三组，分别反映用户在使用软件产品时的三种不同倾向或观点。这三种倾向是：产品运行、产品修改和产品转移。信息系统作为一个产品，也可以参照这三种倾向来定义。,我们需要注意的几个数据,1、在项目发布后发现和修复Bug的成本是需求和设计阶段所需的一百倍！ 2、80%可避免的重复劳动源自于20%的缺陷，其中两大主要来源包括草率的需求定制和象征性的案例设计和开发。 3、大约80%的缺陷来自20%的模块，而约半数的模块是几乎没有缺陷。 4、90%的软件的停工期最多来自于10%的缺陷。,总结一下,上面四条原则说明了两个问题， 一是错误越早发现成本越低，而且大部分的错误都是在软件开发的前面阶段引入的。 二是大部分的错误都集中在少数的模块。,缺陷代价曲线,软件质量的过去,20 世 纪60年代中期，美国的首次金星探测计划，因为在FORTRAN语言程 序 的 D O 语 句 中漏掉一个逗号，惨遭失败。 1996年，欧洲航天局首次发射阿丽亚娜5号火箭失败，其直接原因是火箭控制系统的软件故障，导致直接经济损失5亿美元，还使耗资80亿美元的开 发 计 划 延迟了三年。 1986年3月到1987年1月，由加拿大原子能有限公司生产的Therac 25 放射治疗机 造 成 两人死亡、数人受伤。,软件质量的过去,1992年，法国伦教由于救护派遗系统全部崩溃，导致多名病人因为抢救不及时而失去生命。 1991 年海湾战争期间，美国爱国者导弹由于软件计时系统累计误差造成拦截失败 ，造 成人员无辜伤亡。 1990年美国电话系统中新投入使用的软件发生失效，导致主千线远程网大规模崩溃 ，给运营商造成了重大的经济损失。 1991年，由于一系列局域电话网因软件错误而中断，造成了数以千计依靠电讯公司运营业务的公司遭受巨额的资金损失。,软硬件产品的不同点,软硬件开发过程的比较,我们遇到了什么？,项目没有被很好地理解；计划不周，最终导致进度拖延。 没有充分的文档资料。 人与人的交流比写程序困难得多。 软件可靠性缺少度量的标准，质量无法保证。 软件难以维护、不易升级，问题越改越多。,如何改进我们的软件质量的思考,从一个企业的长远发展来看，首先应当从流程抓起，规范软件产品的开发过程。这是一个软件企业从小作坊的生产方式向集成化、规范化的大公司迈进的必经之路，也是从根本上解决质量问题，提高工作效率的一个关键手段。,瀑布模型,编程,设计,需求分析,测试,维护,瀑布模型是应用的最为广泛的一种模型，也是最容易理解和掌握的模型，然而它的缺陷也是显而易见的。遗漏的需求或者不断变更的需求会使得该模型无所适从。然而，对于那些容易理解但很复杂的项目，采用瀑布模型会是比较适合的，因为你可以按部就班的去处理复杂的问题。在质量要求高于成本和进度要求的时候，该模型表现的尤其突出。,RAD模型（V模型）,螺旋模型,（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；,（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；,（3） 实施工程：实施软件开发和验证；,（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。,螺旋型项目从小的规模开始，然后探测风险，制定风险控制计划，接着确定下一步项目是否还要继续，然后进行下一个螺旋的反复。该模型的最大优点就是随着成本的增加，风险程度随之降低。然而螺旋模型的缺点是比较复杂，且需要管理人员有责任心，专注以及有管理方面经验。,RUP （ Rational Unified Process ）,RUP 工作流程示意图,IPD （ Integrated Product Development ）,IPD 流程示意图,目前主要的一些软件开发过程模型,瀑布模型 原型模型 快速应用开发(RAD)模型 螺旋模型 喷泉模型 增量模型和迭代模型 构件组装模型 并发模型,流程与技术,流程和成功不是等价的。没有流程就成功是不可能得到保证，但有了流程并不意味着肯定能够成功。这恐怕是很多迷信于流程的人所不能接受的。但这的确是个事实。记得有个做了将近 30 多年的需求分析专家说过：即使是一个已经达到 CMM4 级的公司，也完全有可能做不好需求分析。为什么？技术，技术是成功的另外一个必要条件,总之流程很关键，技术也很重要，我的观点是：鱼和熊掌，两者都不能放。,我们的遇到的问题,对于软件开发来说，要保证软件的质量，需要掌握多方面的技术，包括 分析技术 设计技术、 编码技术 测试技术 在国内有一个普遍的非正常现象，就是大家觉得只有编程能力才是玩电脑的真正技能。就好像造一套房子，其它都不重要，只要砖瓦匠有高超的技能就行了。尽管这个比喻会打击很多程序员的自尊心，但这的确是一个事实。我们缺少系统级的工程师，在分析和设计方面的工作做得很不扎实。,我们需要做好的地方,UML 代表软件建模的发展趋势 需求分析的能力 学习好设计模式 测试技术 程序员也要有扎实的文档编写能力 良好的编程习惯,关于软件测试,软件测试是软件质量控制中的关键活动。业界的统计数据表明，测试的成本大约占软件开发总成本的 50 左右。 软件测试的目的是要发现软件中的错误。一个好的测试是发现至今没有被发现的错误。传统的软件测试专注于动态测试范畴，如：单元测试，集成测试和系统测试。而测试工程的发展已经进入到了全流程的测试，包括开发过程前期的静态测试,关于测试的一些介绍,白盒测试 黑盒测试 单元测试 集成测试 系统测试,改善软件质量的技术,软件质量目标 明确定义质量保证工作 测试策略 软件工程指南 非正式技术复查（review,walk-through) 正式技术复查 外部审查,缺陷检测率,国际上流行的质量标准 （CMM),软件能力成熟度模型是目前国内软件企业中非常受欢迎的一个质量标准。并且该标准已经成为业界一个事实上的标准。 CMM 为软件组织提供了一个指导性的管理框架。在这个框架的指导下： 软件组织可以对其软件开发、维护过程获得控制。 软件组织可以推进其软件工程更为科学、推进软件过程管理更为卓越。 CMM 通过确定当前软件过程管理的成熟度，通过标识软件的质量和过程改进中关键的、要害的问题，可以指导软件组织选择正确的软件过程改进策略。 CMM 将其焦点，聚焦在一系列具体的软件过程活动上，并以侵略方式（ Aggressively ）达到这些活动。一个软件组织就可以稳定地、持续地改进其整个软件组织过程，使得其软件过程管理能力取得持续地、持久地不断争长提高。,CMM的五个等级,在 CMM 中，把软件工厂分为五个等级： 初始级 可重复级 已定义级 管理级 优化级,CMM的等级说明,CMM 级别与软件质量关系表格,改进我们的软件质量吧,改进我们的软件质量吧,加强编程规范工作,进行适当的测试工作，建议进行单元测试和系统测试,实施配置管理工作，加强版本控制,开展走读、评审和检视活动，尤其要加强代码走读，建议进行每日交叉走读活动,进行简单的度量分析获得质量数据,给软件开发人员的一些忠告,我的源代码给猫吃了！？,交流！,知道你要说什么,了解你听众,选择时机，选择风格,让文档美观,让听众参与,做倾听者,回复他人,重复的危害,不要重复你自己,让复用变的更容易,软件的正交性,如果显著的改变某个特定功能背后的需求，有多少模块会受影响？,软件的正交性,让你的代码保持解耦 避免使用全局变量 避免编写相似的函数 单元测试,曳光弹,使用曳光弹找到目标 用户能够及早看到能工作的东西 开发者构建了一个他们能够在其中工作的结构 你有了一个集成平台 你有了可以演示的东西 你将更能够感觉到工作的进展,曳光代码,原型制作,估算,检查需求 分析风险 设计，实现，集成 向用户确认,我等会回答你！,源代码控制,总是应该使用源代码控制,按照合约进行设计（DBC),前条件 后条件 类不变项,死程序不说谎,要崩溃，不要破坏（早崩溃） 如果它不可能发生，用断言保证它不会发生,这绝不会发生！,接耦和得墨涅尔法则,关注“正交”和“按照合约设计”,如果N个对象全都互相了解，那么对一个对象的改动就可能导致其他n-1个对象都需要改动,靠巧合编程,它也许不是真的能工作-它也许知识看起来能工作 你依靠的边界也许只是一个偶然，在不同的情况下，它的表现或许就不同。 没有计入文档的行为可能会随着库的下一次发布而变化 多余的和不必要的调用会使你的代码变慢 多余的调用还会增加引入他们自己的新BUG的风险,重构,在什么时候开始重构？ 重复 非正交的设计 过时的知识 性能 早重构，常重构,面向对象设计的原则,单一职责原则（SRP) 开放-封闭原则(OCP) Liskov替换原则(LSP) 依赖倒置原则(DIP) 接口隔离原则(ISP