质量行为检查内容

欢迎阅读本文档，希望本文档能对您有所帮助!欢迎阅读本文档，希望本文档能对您有所帮助!感谢阅读本文档，希望本文档能对您有所帮助!感谢阅读本文档，希望本文档能对您有所帮助!欢迎阅读本文档，希望本文档能对您有所帮助!感谢阅读本文档，希望本文档能对您有所帮助!质量行为检查内容一、是否超越本单位资质等级承揽工程

1、公司营业执照、资质等级和资信证明※

2、施工合同及补充合同

二、有无允许其他单位或个人以本单位的名义承揽工程

1、施工合同及补充合同

2、分包合同，包括材料、设备和班组※

三、有无违法分包所承揽的工程

1、分包合同，包括材料、设备和班组※

四、质量责任制的建立与落实

1、项目部质量目标※

2、项目部管理人员质量责任制※

3、项目部质量责任制落实情况考核※

4、公司对项目部质量检查记录※

5、项目部质量检查记录※

6、质量技术交底

7、分项分部工程质量自检表

8、隐蔽验收记录

五、是否对分包单位工程质量负责

1、施工合同及补充合同

2、分包合同※

六、按设计施工图执行

1、施工图纸（要求在施工图纸上标注修改项）※

2、设计变更以及工程联系单

3、施工方案和施工组织设计

七、是否有偷工减料

1、原材料检验报告

2、原材料合格证和出厂证明

八、是否擅自修改工程设计（同七）

九、出现质量问题是否及时返修

1、质监部门、业主、监理发放的整改通知以及处理意见和结果

2、质量问题整改措施及处理结果※

十、职工培训是否到位

1、职工培训计划

2、职工培训记录摘要

本文的目的是比较软件质量和软件风险管理之间的关系。文章首先回顾了基本原理、技术，以及它们在质量软件开发过程中的应用。读者可以知道风险管理的基本概念，包括Boehmis的六步风险管理过程。文章讨论了质量软件技术是如何既是软件开发风险的贡献者又是缓和者。

质量入门介绍

根据国际标准组织（ISO）的定义，质量是依靠特定的或暗指的能力满足特定需要的产品或服务的全部功能和特征。这个定义说明了质量是产品的内在特征，描绘了产品的质量观点。第二个学术派的观点坚持如果要达到质量的目标必须在这个质量的概念上要加强。这个学派认为，质量不是单独以产品为中心的，而是和客户和产品都有联系的，其中客户是出资金者或受影响的部分人，而产品包括利益和服务。进一步讲，质量的概念会随着时间响应和环境价值的改变而改变，价值会使人们弄清什么是好的、什么是不好的。因此，软件的质量作为产品或服务需要的功能/特征，也必须定位于客户和组织间的内容(R.T.Vidgen,A.T.Wood-Harper)。这是关于质量的有用的观点。这些回顾的细节包含在以下几段文字里，第一步是人为因素。

质量观点

对于质量的观点，开发过程中的每个人都有不同的看法和矛盾。以下几点由开发过程中的几个关键角色提供的简要描述：

*开发经理：产品是可靠的、可维护性好的，能够让客户满意，如此直到项目结束或强制终止（这导致折衷的需要）。

*商业分析者：客户和开发小组联合，保护用户定义的功能和需求不受外部改变干扰。

*QA审计师：发现从质量方案/产品中脱轨的现象——所有使过程偏离质量控制的活动将受到与项目有关的人员的反对。

*最终用户：初级雇员很少给系统输入什么，但是对它的操作必须有责任。最终用户不满意，当他们不愿意为系统付支票时，就需要监察系统的可接受程度了。

*生产线经理：最终用户的老板通常持有这样的态度，即他们不需要太大的时间周期。

*项目投资者：付钞票的人，需要按时、按预算地交付产品。

最后，是开发人员的质量观点，这直接影响到选择最终产品生产的方法。这不仅起源于开发者的质量观点（产品相对于使用），也起源于如何获得需求（主管相对于客观），和他们如何创造他们工作的环境（协调相对于冲突）。R.T.Vidgen和A.T.Wood-Harper提出了四种可能的开发者对质量的认识观点：

*客观的/协调的：在目标没有问题并且得到很好的描述时，开发人员会客观地认为质量是一个合理的工程过程。质量是和详细阐述、实现开发过程严格控制的需要结合的。开发者趋向于接受质量是产品的属性的观点（这是目前大多数软件工程师的观点）。

*客观的/矛盾的：开发者不仅明白质量是客观的，而且理解矛盾的兴趣是可以解决的，于是不可能满足所有人的质量需求，而会确定满足谁的需求（使管理者的还是工人的呢？）。

*客观的/一致的：开发者认为质量关系到团体的结构，要解决许多不同团体（投资者/受益者）的不同的观点和兴趣。最终的结果反映了不同观点的一致意见。

*客观的/矛盾的：开发者考虑了不同的观点和兴趣，但是，假定会有冲突和功能上的限制，解放者构造质量的新思路，这要求满足多的兴趣而忽视少部分功能。这一点更像一种协调而不是意见统一。

质量特征和属性

所有学派都认为质量软件有两个有区别的特征：第一，即是规范的一致性（如这是一个好的方案吗？），第二，即适合它的有意的目标（是问题的正确定位吗？）。另外，所有学派都认为有一个构成高质量的软件的属性。搜索有关不同质量相关的文献都会有许多不同的属性列表，下面是Glass建议的七个属性：

轻便性：允许软件能够从一台计算机很容易地传输到另一台需要运行的计算机上的能力。

可靠性：软件正确无误地满足需求的能力。

效率：软件最小是用计算机资源（如内存、外存和机器时钟周期等）的能力。

人性化工程：软件能够容易地被人们理解和学习的能力。

易测性：为了测试软件的可执行性能的测试能力。

可理解性：软件能够被软件维护人员阅读并理解的方便程度。

可修改性：软件能够被软件维护人员修改的方便程度。

以上例出的属性并没有一个特定的先后顺序，就像质量本身一样，对这些属性没有绝对的层次关系。不是所有这些属性在任何软件工程项目里都有用。此外，用于实现这些属性的技术可能导致确实的、消极的相互冲突。因此，质量属性的优先此序列表必须在程序开发生命期之前定义，以弥补程序目标的不足和在各属性之间保留一定距离。

质量法则

有一条规律可以决定软件开发过程是如何引入软件质量因素的，那就是质量法则。软件开发团体已经认识到这个问题，并认为这有助于对生产软件过程的风险测试。在软件质量书籍《软件开发和支持成功框架》中，Curran和Sanders指出，软件质量过程要注意四点：

*从一开始就要保证不出错，至少应该努力是错误尽量不在代码是发生。为了做到这一点包括采用适当的软件工程标准和过程，建立独立的质量保证将来标准和过程；根据过去的经验和教训制订正式的方法；象软件工具和合同软件一样的高质量输入。

*确保尽早发现错误并纠正，错误隐蔽得越久，修正错误花得代价就越大。因此，质量控制必须在开发生命周期重的每一个阶段都要重视，如需求分析、设计、文档和代码。这些都隶属于所有的回顾方法，如检查、预排和技术回顾。

*消除引起错误的引导因素，还没有找到错误的诱因就纠正错误是不巧党的。通过排除错误的诱因你就达到了改良过程的目的（回忆连续改良过程是全面质量管理TQC原则中用于软件质量的另一个关键原则）。

*运用独立的按照标准和过程来的质量审核工作方式，通常有两种方法用于检查项目活动是否按照预定的标准和过程进行的，即SEI和SPR。

质量因素和风险

我们已经讨论了质量，接下来的问题就是软件质量，或程序的质量，在软件开发项目中要讨论的风险因素。在《软件风险的评估和控制》一书中，Jones描述了他在软件开发中的评估经验。运用软件生产力研究(SPR，SoftwareProductivityResearch)和软件工程技术（SEI，SoftwareEngineeringInstitute）方法来回顾几百个企业的项目，这些项目产生的软件可以分为六类：

*管理信息系统：财务和管理系统；

*象操作系统、通讯软件或其他物理设备控制软件等系统软件；

*商务开发项目，如给最终用户出租/出售产品等；

*军事软件项目；

*合同/采购软件项目（民间），一些零散的用于职员和雇主的客户端软件；

*最终用户软件项目，即一些给特定的用户开发的软件。

这些程序中有超过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%）

不充分的用户文档定义为不完整的、不清楚的、错误的或理解有困难的用户信息。用户信息包括在线帮助和出版材料，这在商业软件世界里是广泛存在的问题。这个问题可以有一下因素来描述：

*技术描述缺乏相当的技巧

*用户文档不充分：

n新的软件包发布的文档每次都很困难；

n一些厂商不愿使用有能力的作者；

n用户文档的陈述还是很原始的方法；

低的用户满意度意味着用户对以下一点或多个因素不满意（在1993年，一半多商业软件存在这些问题）：

*低质量；

*不完整的功能；

*复杂的不可思议的命令结构；

*很难学习；

*麻烦的安装过程；

*用户服务和支持力量不足；

*过多的占用磁盘空间或其他硬件资源；

军用软件

据用软件有相当严格的项目连续性，同时也有其相应的代价高昂的问题和风险。

*过多的文档（90%）

*低产率（85%）

*长周期（75%）

*缓慢的用户需求（70%）

*不用或不能用的软件（45%）

合同/采购软件项目风险

*高维护费用（60%）

*委托人和承包人间的摩擦（50%）

*缓慢的用户需求（45%）

*不可预料的认可标准（30%）

*交付的软件法律所有权（20%）

维护费用是指每年一次的修复错误或按照显著高于U.S标准的项目维护费用，一个人能够维护的目前软件总数显著的低于U.S标准。

不可预料的标准认可定义为有时存在项目委托人和承包人之间的对于产品交付条件、付款、超出最初的合同或协议的条件方面的问题。例如一个典型的问题就是过高的质量要求、对软件性能目标的过高要求，或者软件的特殊需要或文档。这种情况最终会使认可失败，或导致用户感到工作不满意。这会对项目造成伤害，影响客户关系，极端的情况会引起法律诉讼。

最终用户软件风险

*不可转让的应用（80%）

*隐藏的错误（65%）

*不可维护的软件（60%）

*多余的应用（50%）

*交付的物品和软件的法律关系（版权）（20%）

应藏错误定义为隐藏在最终用户系统中不为开发者或任何其他人知道的逻辑或程序错误。在没有最后回顾、检查、测试、审核和质量分析活动的情况下更容易出现。

不可维护的软件。一旦软件开发者离开了公司之后，谁来维护软件呢？一些应用软件机构化很差、注释不全，以至于一旦开发者离开了公司，就没有谁能够维护该软件了。

Boehmis的六步风险管理

正如Jones所说，质量保证活动直接影响到软件开发过程的风险。目前的软件风险管理已经从概念、实践和规则方面同其他工程或管理领域对应起来。软件风险管理的目标用于标识、定位和消除各种风险因素，在其来临之前阻止其发生，以使项目成功操作或使软件重写的机率降低。这种征兆是在一定条件下发生的。如果操作者不注意，这些风险可能就会趁你不注意发生。决策树结构显示了复合风险是由每个决策项构成的，复合风险是各部分风险的综合。这种决策树提供了一种量化的用于描述不同的选项影响程度的方法，就像决定各个风险因素部分的决策参数。这种分析方法在风险发生概率和没有精确的分析方法时很有用。

Boehm归纳了六步风险管理法则，其中有两步关键法则，每个法则有三个子步骤。Boehm建议采用适当的技术来实现每个关键步骤和子步骤。第一步是评估，包括：

*风险确认，确认详细的影响软件成功的项目风险因素；

*风险分析，检查每个风险因素的发生概率和降低其发生的概率的可能性；

*给确认和分析的风险因素确定级别，即风险考虑的先后顺序；

一旦项目风险因素的先后顺序排列出来了，第二步就是风险管理。这一步中，要对这些风险因素进行控制，包括：

*风险管理计划，制定每个风险因素如何定位，这些风险因素的管理如何与整个项目计划融为一体；

*在每个实现活动或工作中的风险解决方案，消除或解决风险因素的特殊活动；

*风险监视，跟踪解决风险活动的风险过程的趋势；

质量因素的风险管理应用

正如我在本文的“质量因素和风险”一节中提到的，几种方式的软件开发直接或间接地受到相关的软件质量问题影响，在本节中，我们要讨论几种可以帮助我们控制、减轻或防止风险发生的技巧。（Jones）

因素：缓慢的用户需求

减轻风险的技巧：

*使用原型；

*在MIS系统中利用JADS技术分析需求；

*使用信息工程（IE）技术创建需求——主要使用在MIS系统中；

*运用功能规格方法监视需求的进展，一旦在需求阶段确定了规格，研究就是和需求收集过程结合起来了。现在创建需求功能列表的自动工具技术是可行的了。这些工具的先进之处在于：严格而快速地收集需求，不仅可以填写功能点计算和成本预算，也能够把这些数据增加到CASE工具、数据模