质量入门介绍
根据国际标准组织（ISO）的定义，质量是依靠特定的或暗指的能力满足特定需要的产品或服务的全部功能和特征。这个定义说明了质量是产品的内在特征，描绘了产品的质量观点。第二个学术派的观点坚持假如要达到质量的目标必须在这个质量的概念上要加强。这个学派认为，质量不是单独以产品为中心的，而是和客户和产品都有联系的，其中客户是出资金者或受影响的部分人，而产品包括利益和服务。进一步讲，质量的概念会随着时间响应和环境价值的改变而改变，价值会使人们弄清什么是好的、什么是不好的。因此，软件的质量作为产品或服务需要的功能/特征，也必须定位于客户和组织间的内容(R.T. Vidgen,A.T. Wood-Harper)。这是关于质量的有用的观点。这些回顾的细节包含在以下几段文字里，第一步是人为因素。
质量观点
对于质量的观点，开发过程中的每个人都有不同的看法和矛盾。以下几点由开发过程中的几个要害角色提供的简要描述：
* 开发经理：产品是可靠的、可维护性好的，能够让客户满足，如此直到项目结束或强制终止（这导致折衷的需要）。
* 商业分析者：客户和开发小组联合，保护用户定义的功能和需求不受外部改变干扰。
* QA审计师：发现从质量方案/产品中脱轨的现象——所有使过程偏离质量控制的活动将受到与项目有关的人员的反对。
* 最终用户：初级雇员很少给系统输入什么，但是对它的操作必须有责任。最终用户不满足，当他们不愿意为系统付支票时，就需要监察系统的可接受程度了。
* 生产线经理：最终用户的老板通常持有这样的态度，即他们不需要太大的时间周期。
* 项目投资者：付钞票的人，需要按时、按预算地交付产品。
最后，是开发人员的质量观点，这直接影响到选择最终产品生产的方法。这不仅起源于开发者的质量观点（产品相对于使用），也起源于如何获得需求（主管相对于客观），和他们如何创造他们工作的环境（协调相对于冲突）。R.T.Vidgen和A.T.Wood-Harper提出了四种可能的开发者对质量的熟悉观点：
* 客观的/协调的：在目标没有问题并且得到很好的描述时，开发人员会客观地认为质量是一个合理的工程过程。质量是和具体阐述、实现开发过程严格控制的需要结合的。开发者趋向于接受质量是产品的属性的观点（这是目前大多数软件工程师的观点）。
* 客观的/矛盾的：开发者不仅明白质量是客观的，而且理解矛盾的爱好是可以解决的，于是不可能满足所有人的质量需求，而会确定满足谁的需求（使治理者的还是工人的呢？）。
* 客观的/一致的：开发者认为质量关系到团体的结构，要解决许多不同团体（投资者/受益者）的不同的观点和爱好。最终的结果反映了不同观点的一致意见。
* 客观的/矛盾的：开发者考虑了不同的观点和爱好，但是，假定会有冲突和功能上的限制，解放者构造质量的新思路，这要求满足多的爱好而忽视少部分功能。这一点更像一种协调而不是意见统一。
质量特征和属性
所有学派都认为质量软件有两个有区别的特征：第一，即是规范的一致性（如这是一个好的方案吗？），第二，即适合它的有意的目标（是问题的正确定位吗？）。另外，所有学派都认为有一个构成高质量的软件的属性。搜索有关不同质量相关的文献都会有许多不同的属性列表，下面是Glass建议的七个属性：
轻便性：答应软件能够从一台计算机很轻易地传输到另一台需要运行的计算机上的能力。
可靠性：软件正确无误地满足需求的能力。
效率：软件最小是用计算机资源（如内存、外存和机器时钟周期等）的能力。
人性化工程：软件能够轻易地被人们理解和学习的能力。
易测性：为了测试软件的可执行性能的测试能力。
可理解性：软件能够被软件维护人员阅读并理解的方便程度。
可修改性：软件能够被软件维护人员修改的方便程度。
以上例出的属性并没有一个特定的先后顺序，就像质量本身一样，对这些属性没有绝对的层次关系。不是所有这些属性在任何软件工程项目里都有用。此外，用于实现这些属性的技术可能导致确实的、消极的相互冲突。因此，质量属性的优先此序列表必须在程序开发生命期之前定义，以弥补程序目标的不足和在各属性之间保留一定距离。
质量法则
有一条规律可以决定软件开发过程是如何引入软件质量因素的，那就是质量法则。软件开发团体已经熟悉到这个问题，并认为这有助于对生产软件过程的风险测试。在软件质量书籍《软件开发和支持成功框架》中，Curran和Sanders指出，软件质量过程要注重四点：
* 从一开始就要保证不出错，至少应该努力是错误尽量不在代码是发生。为了做到这一点包括采用适当的软件工程标准和过程，建立独立的质量保证将来标准和过程；根据过去的经验和教训制订正式的方法；象软件工具和合同软件一样的高质量输入。
* 确保尽早发现错误并纠正，错误隐蔽得越久，修正错误花得代价就越大。因此，质量控制必须在开发生命周期重的每一个阶段都要重视，如需求分析、设计、文档和代码。这些都隶属于所有的回顾方法，如检查、预排和技术回顾。
* 消除引起错误的引导因素，还没有找到错误的诱因就纠正错误是不巧党的。通过排除错误的诱因你就达到了改良过程的目的（回忆连续改良过程是全面质量治理TQC原则中用于软件质量的另一个要害原则）。
* 运用独立的按照标准和过程来的质量审核工作方式，通常有两种方法用于检查项目活动是否按照预定的标准和过程进行的，即SEI和SPR。
质量因素和风险
我们已经讨论了质量，接下来的问题就是软件质量，或程序的质量，在软件开发项目中要讨论的风险因素。在《软件风险的评估和控制》一书中，Jones描述了他在软件开发中的评估经验。运用软件生产力研究(SPR，Software ProdUCtivity Research)和软件工程技术（SEI，Software Engineering Institute）方法往返顾几百个企业的项目，这些项目产生的软件可以分为六类：
* 治理信息系统：财务和治理系统；
* 象操作系统、通讯软件或其他物理设备控制软件等系统软件；
* 商务开发项目，如给最终用户出租/出售产品等；
* 军事软件项目；
* 合同/采购软件项目（民间），一些零散的用于职员和雇主的客户端软件；
* 最终用户软件项目，即一些给特定的用户开发的软件。
这些程序中有超过100多个的风险因素。少数项目有超过15个风险因素，但大多数是6个因素影响。分析这些项目中的风险模式，结论是它们不都是所有软件中的共同因素。这儿列出了几个在样本程序中出现最多的风险因素。
MIS：
* 缓慢的用户需求分析（80%）
* 过大的时间进度压力（65%）
* 低质量（60%）
* 严重超成本（55%）
* 不充分的配置控制（50%）
低质量的软件被定义为根本不工作，或是重复出现操作失败的现象。Jones定义低质量的软件是，用户报告中每日历年、每个功能点出现超过0.5个错误。MIS系统低质量表现在两个方面：(1)不确定的错误出现，如偶然或非专业的使用检查或运行测试时出现错误；（2）不充分的错误预防，如使用象联合应用设计（JAD）或信息工程(IE)的标准技术失败，一些错误可以产生项目的说明。
系统软件风险：
* 长期的计划（70%）
* 不充分的成本估计（65%）
* 过多的文档工作（60%）
* 错误的模块（50%）
* 项目取消（35%）
过多的文档工作并没有严格的规律，但是可以从以下几点来判定是否是“过多”：（1）超过50种分散类型的文档；（2）文档费用接近或超过了整个项目费用的50%；（3）每个功能点有超过2000词的描述。系统软件的文档在数量级上仅次于军事软件，太多的文档对工作来讲是多余的。(注重，过多的文档会引起额外的问题，目前，还没有出版相关的作品说明怎样数量、卷、结构或什么样的文档风格对于软件项目来讲是合适的。)
商业软件风险
* 不充分的用户文档（70%）
* 低用户满足度（55%）
* 太多的市场营销时间（50%）
* 有害的竞争活动（45%）
* 诉讼费用（40%）质量入门介绍
根据国际标准组织（ISO）的定义，质量是依靠特定的或暗指的能力满足特定需要的产品或服务的全部功能和特征。这个定义说明了质量是产品的内在特征，描绘了产品的质量观点。第二个学术派的观点坚持假如要达到质量的目标必须在这个质量的概念上要加强。这个学派认为，质量不是单独以产品为中心的，而是和客户和产品都有联系的，其中客户是出资金者或受影响的部分人，而产品包括利益和服务。进一步讲，质量的概念会随着时间响应和环境价值的改变而改变，价值会使人们弄清什么是好的、什么是不好的。因此，软件的质量作为产品或服务需要的功能/特征，也必须定位于客户和组织间的内容(R.T. Vidgen,A.T. Wood-Harper)。这是关于质量的有用的观点。这些回顾的细节包含在以下几段文字里，第一步是人为因素。
质量观点
对于质量的观点，开发过程中的每个人都有不同的看法和矛盾。以下几点由开发过程中的几个要害角色提供的简要描述：
* 开发经理：产品是可靠的、可维护性好的，能够让客户满足，如此直到项目结束或强制终止（这导致折衷的需要）。
* 商业分析者：客户和开发小组联合，保护用户定义的功能和需求不受外部改变干扰。
* QA审计师：发现从质量方案/产品中脱轨的现象——所有使过程偏离质量控制的活动将受到与项目有关的人员的反对。
* 最终用户：初级雇员很少给系统输入什么，但是对它的操作必须有责任。最终用户不满足，当他们不愿意为系统付支票时，就需要监察系统的可接受程度了。
* 生产线经理：最终用户的老板通常持有这样的态度，即他们不需要太大的时间周期。
* 项目投资者：付钞票的人，需要按时、按预算地交付产品。
最后，是开发人员的质量观点，这直接影响到选择最终产品生产的方法。这不仅起源于开发者的质量观点（产品相对于使用），也起源于如何获得需求（主管相对于客观），和他们如何创造他们工作的环境（协调相对于冲突）。R.T.Vidgen和A.T.Wood-Harper提出了四种可能的开发者对质量的熟悉观点：
* 客观的/协调的：在目标没有问题并且得到很好的描述时，开发人员会客观地认为质量是一个合理的工程过程。质量是和具体阐述、实现开发过程严格控制的需要结合的。开发者趋向于接受质量是产品的属性的观点（这是目前大多数软件工程师的观点）。
* 客观的/矛盾的：开发者不仅明白质量是客观的，而且理解矛盾的爱好是可以解决的，于是不可能满足所有人的质量需求，而会确定满足谁的需求（使治理者的还是工人的呢？）。
* 客观的/一致的：开发者认为质量关系到团体的结构，要解决许多不同团体（投资者/受益者）的不同的观点和爱好。最终的结果反映了不同观点的一致意见。
* 客观的/矛盾的：开发者考虑了不同的观点和爱好，但是，假定会有冲突和功能上的限制，解放者构造质量的新思路，这要求满足多的爱好而忽视少部分功能。这一点更像一种协调而不是意见统一。
质量特征和属性
所有学派都认为质量软件有两个有区别的特征：第一，即是规范的一致性（如这是一个好的方案吗？），第二，即适合它的有意的目标（是问题的正确定位吗？）。另外，所有学派都认为有一个构成高质量的软件的属性。搜索有关不同质量相关的文献都会有许多不同的属性列表，下面是Glass建议的七个属性：
轻便性：答应软件能够从一台计算机很轻易地传输到另一台需要运行的计算机上的能力。
可靠性：软件正确无误地满足需求的能力。
效率：软件最小是用计算机资源（如内存、外存和机器时钟周期等）的能力。
人性化工程：软件能够轻易地被人们理解和学习的能力。
易测性：为了测试软件的可执行性能的测试能力。
可理解性：软件能够被软件维护人员阅读并理解的方便程度。
可修改性：软件能够被软件维护人员修改的方便程度。
以上例出的属性并没有一个特定的先后顺序，就像质量本身一样，对这些属性没有绝对的层次关系。不是所有这些属性在任何软件工程项目里都有用。此外，用于实现这些属性的技术可能导致确实的、消极的相互冲突。因此，质量属性的优先此序列表必须在程序开发生命期之前定义，以弥补程序目标的不足和在各属性之间保留一定距离。
质量法则
有一条规律可以决定软件开发过程是如何引入软件质量因素的，那就是质量法则。软件开发团体已经熟悉到这个问题，并认为这有助于对生产软件过程的风险测试。在软件质量书籍《软件开发和支持成功框架》中，Curran和Sanders指出，软件质量过程要注重四点：
* 从一开始就要保证不出错，至少应该努力是错误尽量不在代码是发生。为了做到这一点包括采用适当的软件工程标准和过程，建立独立的质量保证将来标准和过程；根据过去的经验和教训制订正式的方法；象软件工具和合同软件一样的高质量输入。
* 确保尽早发现错误并纠正，错误隐蔽得越久，修正错误花得代价就越大。因此，质量控制必须在开发生命周期重的每一个阶段都要重视，如需求分析、设计、文档和代码。这些都隶属于所有的回顾方法，如检查、预排和技术回顾。
* 消除引起错误的引导因素，还没有找到错误的诱因就纠正错误是不巧党的。通过排除错误的诱因你就达到了改良过程的目的（回忆连续改良过程是全面质量治理TQC原则中用于软件质量的另一个要害原则）。
* 运用独立的按照标准和过程来的质量审核工作方式，通常有两种方法用于检查项目活动是否按照预定的标准和过程进行的，即SEI和SPR。
质量因素和风险
我们已经讨论了质量，接下来的问题就是软件质量，或程序的质量，在软件开发项目中要讨论的风险因素。在《软件风险的评估和控制》一书中，Jones描述了他在软件开发中的评估经验。运用软件生产力研究(SPR，Software Productivity Research)和软件工程技术（SEI，Software Engineering Institute）方法往返顾几百个企业的项目，这些项目产生的软件可以分为六类：
* 治理信息系统：财务和治理系统；
* 象操作系统、通讯软件或其他物理设备控制软件等系统软件；
* 商务开发项目，如给最终用户出租/出售产品等；
* 军事软件项目；
* 合同/采购软件项目（民间），一些零散的用于职员和雇主的客户端软件；
* 最终用户软件项目，即一些给特定的用户开发的软件。
这些程序中有超过100多个的风险因素。少数项目有超过15个风险因素，但大多数是6个因素影响。分析这些项目中的风险模式，结论是它们不都是所有软件中的共同因素。这儿列出了几个在样本程序中出现最多的风险因素。
MIS：
* 缓慢的用户需求分析（80%）
* 过大的时间进度压力（65%）
* 低质量（60%）
* 严重超成本（55%）
* 不充分的配置控制（50%）
低质量的软件被定义为根本不工作，或是重复出现操作失败的现象。Jones定义低质量的软件是，用户报告中每日历年、每个功能点出现超过0.5个错误。MIS系统低质量表现在两个方面：(1)不确定的错误出现，如偶然或非专业的使用检查或运行测试时出现错误；（2）不充分的错误预防，如使用象联合应用设计（JAD）或信息工程(IE)的标准技术失败，一些错误可以产生项目的说明。
系统软件风险：
* 长期的计划（70%）
* 不充分的成本估计（65%）
* 过多的文档工作（60%）
* 错误的模块（50%）
* 项目取消（35%）
过多的文档工作并没有严格的规律，但是可以从以下几点来判定是否是“过多”：（1）超过50种分散类型的文档；（2）文档费用接近或超过了整个项目费用的50%；（3）每个功能点有超过2000词的描述。系统软件的文档在数量级上仅次于军事软件，太多的文档对工作来讲是多余的。(注重，过多的文档会引起额外的问题，目前，还没有出版相关的作品说明怎样数量、卷、结构或什么样的文档风格对于软件项目来讲是合适的。)
商业软件风险
* 不充分的用户文档（70%）
* 低用户满足度（55%）
* 太多的市场营销时间（50%）
* 有害的竞争活动（45%）
* 诉讼费用（40%）
