• 符合实际需求。实际的需求包括用户明确说明的和隐含的需求。
ISO 关于质量的定义表示如下：
“ 一个实体（产品或服务）的所有特性，基于这些特性可以满足明显 的或隐含的需要。 ”
什么是软件质量？
外部用户要求:正确,高效,健壮,易用和可靠 内部维护人员要求:可维护(代码易读,易读, 易Debug,注释清晰,容易扩展) 内部测试人员要求:可测试,易用,易理解 企业产品化要求:可扩展,可移植,可配置,灵活, 重用性高,模块和组件化
可重复级
人们根据多年的经验和教训， 总结出软件开发的首要问题不 是技术问题而是管理问题。因 此，第二级的焦点集中在软件 管理过程上。一个可管理的过 程则是一个可重复的过程，可 重复的过程才能逐渐改进和成 熟。可重复级的管理过程包括 了需求管理、项目管理、质量 管理、配置管理和子合同管理 五个方面；其中项目管理过程 又分为计划过程和跟踪与监控 过程。通过实施这些过程，从 管理角度可以看到一个按计划 执行的且阶段可控的软件开发 过程。
总之流程很关键，技术 也很重要，我的观点是： 鱼和熊掌，两者都不能 放。
我们的遇到的问题
对于软件开发来说，要保证软件的质量，需要掌握多方面的 技术，包括 分析技术 设计技术、 编码技术 测试技术 在国内有一个普遍的非正常现象，就是大家觉得只有编程能 力才是玩电脑的真正技能。就好像造一套房子，其它都不重 要，只要砖瓦匠有高超的技能就行了。尽管这个比喻会打击 很多程序员的自尊心，但这的确是一个事实。我们缺少系统 级的工程师，在分析和设计方面的工作做得很不扎实。
编程
测试 维护
RAD模型（V模型）
螺旋模型
（1） 制定计划：确定软件目标， 螺旋型项目从小的规模开始， 选定实施方案，弄清项目开发 然后探测风险，制定风险控制 的限制条件； 计划，接着确定下一步项目是 否还要继续，然后进行下一个 （2） 风险分析：分析评估所选 螺旋的反复。该模型的最大优 方案，考虑如何识别和消除风 点就是随着成本的增加，风险 险； 程度随之降低。然而螺旋模型 的缺点是比较复杂，且需要管 理人员有责任心，专注以及有 管理方面经验。 （3） 实施工程：实施软件开发 和验证；
从一个企业的长远发展来看，首先应当从流 程抓起，规范软件产品的开发过程。这是一 个软件企业从小作坊的生产方式向集成化、 规范化的大公司迈进的必经之路，也是从根 本上解决质量问题，提高工作效率的一个关 键手段。
瀑布模型
需求分析 设计
瀑布模型是应用的最为广泛的一种模型，也是 最容易理解和掌握的模型，然而它的缺陷也是 显而易见的。遗漏的需求或者不断变更的需求 会使得该模型无所适从。然而，对于那些容易 理解但很复杂的项目，采用瀑布模型会是比较 适合的，因为你可以按部就班的去处理复杂的 问题。在质量要求高于成本和进度要求的时候， 该模型表现的尤其突出。
我们把影响软件质量的因素分成三组，分别反映用户在使用软件产品时的 三种不同倾向或观点。这三种倾向是：产品运行、产品修改和产品转移。 信息系统作为一个产品，也可以参照这三种倾向来定义。
我们需要注意的几个数据
1、在项目发布后发现和修复Bug的成本是需求和设计 阶段所需的一百倍！

2、80%可避免的重复劳动源自于20%的缺陷，其中两 大主要来源包括草率的需求定制和象征性的案例设计和开发。
流程与技术
流程和成功不是等价的。没 有流程就成功是不可能得到 保证，但有了流程并不意味 着肯定能够成功。这恐怕是 很多迷信于流程的人所不能 接受的。但这的确是个事实。 记得有个做了将近 30 多年 的需求分析专家说过：即使 是一个已经达到 CMM4 级 的公司，也完全有可能做不 好需求分析。为什么？技术， 技术是成功的另外一个必要 条件
代码大全怎么说
因此《代码大全》将软件质量特征分为内部质量特征和外部质量特征:
外部质量特征包括: +正确性。整个系统受说明、设计和实现的错误影响程度。 +可用性。用户学会和使用系统的难易程度。 +效率。对系统资源的最小利用，包括存储和执行时间。 +可靠性。在一定条件下执行特定功能的能力。 +完整性。防止非法或不适当地访问。完整性思想包括：限制非 法用户访问，同时确保证数据恰当访问；并行数据表进行并行修 改；数据段仅含有有效数据等等。 +适应性。系统在应用或其它环境下不作修改就能使用的能力。 +精确性。系统不受错误影响的程度，尤其是数据输出方面。精 确性和正确性是不同的。精确性是对系统完成其工作性能良好的 衡量，而不是它设计得是否正确。 +坚固性。系统对无效输入或压力环境中能继续执行其功能的能 力。
软硬件产品的不同点
特征
存在形式
软件
虚拟、动态
硬件
固化、稳定
客户需求 度量性
生产过程 逻辑关系 接口 维护
不确定性 非常困难
逻辑性强 复杂 复杂
相对清楚 正常
流水线、工序 清楚 多数简单、适中
复杂、新的需求、多数简单、适中、 可以不断打补丁 没有新的需求
软硬件开发过程的比较
软件 硬件
54-56%质量缺陷来自需 求不清楚 25%质量缺陷来自设计和 编程
支持原有功能，解决运 行中出现的问题，一般 比较容易预测
维 护
ቤተ መጻሕፍቲ ባይዱ
维 修
我们遇到了什么？
项目没有被很好地理解；计划不周， 最终导致进度拖延。 没有充分的文档资料。 人与人的交流比写程序困难得多。 软件可靠性缺少度量的标准，质量 无法保证。 软件难以维护、不易升级，问题越 改越多。
如何改进我们的软件质量的思考
小于 1
小于 0.1
已定义级
管理级
99
降低开发时 间到 1/2 降低开发时 间到 1/4
2.5Z
5Z
10
5
不确定
不确定
小于 0.01
优化级
代码大全怎么说
内部质量特征包括: +可维护性。修改一个软件系统，提高其性能或修正其错误 的能力。 +灵活性。修改系统使其能适应于不同的用途或环境的能力， 而不必对系统进行特定的设计。 +可移植性。能修改所设计的某一系统使其能在其它环境下 运行的能力。 +可重用性。能将系统的一部分用于其它系统的难易程度。 +可读性。能读懂或理解系统源代码的能力，尤其是在细节 说明这一级上。 +可测试性。对整个系统进行单元或系统测试以证实其满足 所有需求性能的测试难易程度。 +可理解性。能从整个系统水平或细节说明这一级上理解整 个系统的难易程度。可理解性要比可读性从更一般的水平上 讨论系统的紧密性。
软件质量的过去
1992年，法国伦教由于救护派遗系统全部崩溃，导 致多名病人因为抢救不及时而失去生命。 1991 年海湾战争期间，美国爱国者导弹由于软件计 时系统累计误差造成拦截失败 ，造 成人员无辜伤 亡。 1990年美国电话系统中新投入使用的软件发生失效， 导致主千线远程网大规模崩溃 ，给运营商造成了重 大的经济损失。 1991年，由于一系列局域电话网因软件错误而中断， 造成了数以千计依靠电讯公司运营业务的公司遭受 巨额的资金损失。
（4） 客户评估：评价开发工作， 提出修正建议，制定下一步计 划。
RUP （ Rational Unified Process ）
RUP 工作流程示意图
IPD （ Integrated Product Development ）
IPD 流程示意图
目前主要的一些软件开发过程模型
瀑布模型 原型模型 快速应用开发(RAD)模型 螺旋模型 喷泉模型 增量模型和迭代模型 构件组装模型 并发模型
如何提高我们的软件质量
研发中心软件室－王丁 2008-6
主题
什么是软件质量？
软件质量的过去和将来！
我们遇到了什么？或者即将遇到什么？
怎么办？
参考资料
什么是质量？
质量具有三个维度：
• 符合目标。目标是客户所定义的，符合目标即判断我们是不是在做需 要做的事情。
• 符合需求。即产品是不是在做让它做的事情。
关于测试的一些介绍
白盒测试 黑盒测试 单元测试 集成测试 系统测试
改善软件质量的技术
软件质量目标 明确定义质量保证工作 测试策略 软件工程指南 非正式技术复查（review,walk-through) 正式技术复查 外部审查
缺陷检测率
国际上流行的质量标准 （CMM)
3、大约80%的缺陷来自20%的模块，而约半数的模块 是几乎没有缺陷。 4、90%的软件的停工期最多来自于10%的缺陷。


总结一下
上面四条原则说明了两个问题， 一是错误越早发现成本越低，而且大部分的 错误都是在软件开发的前面阶段引入的。 二是大部分的错误都集中在少数的模块。
缺陷代价曲线
软件能力成熟度模型是目前国内软件企业中非常受欢迎的一 个质量标准。并且该标准已经成为业界一个事实上的标准。 CMM 为软件组织提供了一个指导性的管理框架。在这个框 架的指导下： • 软件组织可以对其软件开发、维护过程获得控制。 • 软件组织可以推进其软件工程更为科学、推进软件过程管 理更为卓越。 • CMM 通过确定当前软件过程管理的成熟度，通过标识软 件的质量和过程改进中关键的、要害的问题，可以指导软件 组织选择正确的软件过程改进策略。 • CMM 将其焦点，聚焦在一系列具体的软件过程活动上， 并以侵略方式（ Aggressively ）达到这些活动。一个软件组 织就可以稳定地、持续地改进其整个软件组织过程，使得其 软件过程管理能力取得持续地、持久地不断争长提高。
需求分析 设计、编程 测 试 发 布
《＝》 调研分析 《＝》 设计阶段
质量控制的主要阶段之一 质量控制的主要阶段之一
《＝》 设计审查 《＝》 设计完成