转载iso9000的文章，供大家学习一、软件企业与ISO 9001标准的关系
1.软件企业实施ISO 9001标准的必要性
近年来随着国民经济的快速发展，我国的软件产业从无到有，迅速成长起来，崛起了一批从事软件开发的软件企业，这些企业推出的软件产品能否真正满足用户的需求，为什么要加强软件开发的质量管理和质量保证，特别是为什么要按国际标准ISO 9000建立企业的质量保证体系是本节要讨论的问题。
实际上，不只是从事软件开发的企业，只要是从事软件工程项目的机构都同样要考虑这个问题。
实践表明，从技术上解决软件质量问题的效果十分有限，不存在理想的“外方”。
●构件技术尚未普及。
目前软件开发技术在解决软件组件(component)或构件(build)的可复用性(reusability)问题上仍不够理想。尽管近年来这一问题已经引起了人们的很大关注，并且也取得了一些成果，但软件开发机构在自己的构件工程项目中实际应用的复用率仍然很低。也许这是突破软件危机的一条出路，但至少目前还远没达到预想的境地，软件质量的大幅度提高还是个梦想。
●我们对软件质量本身的认识还很不成熟。
究竟什么是软件质量，怎样衡量软件的质量，即使一位长期在计算机领域工作的专业人员也很难给你一个满意的答复。这并不奇怪，并且责任不在他们，其实并非他们业务水平不高，经验不够，原因在于软件技术的发展在这方面还处在幼稚阶段。
●软件测试技术尚不完美。
在发现错误和排除错误方面，更重要的也是更困难的发现错误，也就是测试，因为只有发现了错误才能去排除它。十分遗憾的是，近年来，软件测试技术并没有多少新的进展。至今众只能沿用传统的所谓白盒测试和黑盒测试的几个方法，除此之外，并没有更新的更高效的测试方法出现。
2.软件生存周期过程
在1976年以前，讲到软件开发很容易理解为“那就是编程序”，随着计算机应用范围不断扩大和深化，软件就越显得高度复杂，也越清楚地认识到软件系统开发与其他工业产品一样，设计、试验、检验等阶段也是必不可少的。自1976年之后，重新注重编程序前的几个开发阶段，至少应有规格说明和设计两个阶段，从而形成了“软件生存周期”这一概念，从而给出了软件生存周期的定义，即软件产品或软件系统从产生、投入使用到淘汰的全过程。一个软件产品的生存周期也和人们的一生相类似，可以划分为若干个互相区别而又彼此联系的阶段，上一阶段的结果为下一阶段的依据，上一阶段没有完成决不进行下一阶段的工作。
通常把软件生存周期分为5个阶段，即需求、设计、实现、测试和维护。需求包括问题分析和需求分析，问题分析获取需求定义，需求分析生成功能规约；设计包括概要设计和详细设计，概要设计建立整个软件体系结构；详细设计产生程序员可用的模块说明、数据结构说明和加工描述；实现是把设计结果转换为可执行的程序代码；测试包括单元测试、软件测试和系统测试，之些测试活动的目的就是使软件系统达到需求阶段提出的各项要求；维护是对投入运作的软件进行修改，使软件适应外界环境的变化，实现功能扩充和质量改善。
随着提高软件生产率和软件质量的要求不断上升，为此人们又认识到关键在于软件开发和维护中的支持和管理问题，为此进行了一系列的研究和讨论，1984年开始掀起《软件过程运动》，认为最关键的是《软件过程》，在此基础上，IEEE标准化委员会于1991年9月制定出《软件生存周期过程开展标准》，接着ISO/IEC于1994年制定出《软件生存周期过程》标准草案，我国根据该草案制定了GB/T 8566-1995《信息技术、软件生存周期过程》国家标准，原本想和国际同步，以此来代替GB/8566-88《计算机软件开发规范》国家标准，但ISO/IEC组织经过多次讨论和修改，于1995年8月1日正式发布了ISO/IEC12207第一版“信息技术—软件生存周期过程”国家标准。
ISO/IEC12207国际标准正文把软件生存周期的各个过程分成三类，即基本生存周期过程、支持生存周期过程和组织的生存周期过程，见图6-1；
获取过程
供应过程
基本过程 开发过程
运作过程
维护过程
文档编制过程
软 配置管理过程
件 质量保证过程
生 验证过程
存 支持过程 确认过程
周 联合评审过程
期 审核过程
过 问题解决过程
程
管理过程
基础设施过程
组织过程 改进过程
培训过程
图6-1 软件过程
基本生存周期过程包括5个过程，这些过程提供主要各当事方在软件生存周期期间使用。主要当事方有软件产品的需方、供方、开发者、操作者和维护者。
●获取过程：确定需方和组织向供方获取系统、软件产品或软件服务的活动。
●供应过程：确定供方和组织向需方提供系统、软件产品或软件服务的活动。
●开发过程：确定开发者和组织定义并开发软件产品的活动。
●运作过程：确定操作者和组织在规定的环境中为其用户提供运行计算机系统服务的活动。
●维护过程：确定维护者和组织提供维护软件产品服务的活动。
支持生存周期过程包括8个过程，以明确的目的支持其他过程，作为其组成部分，它们有助于软件项目的成功和质量提高。
●文档编制过程： 确定记录生存周期过程产生的信息所需的活动。
●配置管理过程：确定配置管理活动。
●质量保证过程：确定客观地保证软件产品和过程符合规定的要求以及已建立的计划所需的活动。
●验证过程：根据软件项目要求，按不同深度确定验证软件产品所需的活动。
●确认过程：确定确认软件项目的软件产品所需的活动。
●联合评审过程：确定评价一项活动的状态和产品所需的活动。
●审核过程：确定为判断符合要求、计划和合同所需的活动。
●问题解决过程：确定一个过程来分析和解决问题（包括不合格）。
组织的生存周期过程包括4个过程，这些过程被某个组织用来建立和实现构成相关生存周期的基础结构和人事制度，并不断改进这种结构和过程。
●管理过程：确定生存周期过程吕的基本管理活动。
●基础设施过程：确定建立生存周期过程基础结构的基本活动。
●改进过程：确定一个组织为建立\测量\控制和改进其生存周期过程所需开展的基本活动。
●培训过程：确定提供经适当培训的人员所需的活动。
剪裁过程是为软件产品进行本标准剪裁所需要的基本活动，可以根据要素作出剪裁决定。
在
该标准中的过程(proxess)概念与ISO 9000中的过程概念是一致的，但对软件过程的描述均以“过程—活动—任务”三层关系给出。
3.软件生存周期开发模型与软件开发方法
我们有时会听到某些软件公司或技术人员讲软件生存周期开发方法或软件生存周期模型，我们认为3 必要澄清这些概念。软件生存周期概念在上一节中我们已作了说明，而软件开发模型是指软件开发全部过程、活动和任务的结构框架，软件开发包括需求、设计、实现、测试等阶段，有时也包括维护阶段。也就是说软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，它用作软件项目工作的基础。
最早出现的软件开发模型是1970年W.Royce提出的瀑布模型(waterfallmodel)。该模型给出了固定顺序，从上一阶段向下一阶段过渡，如同流水下泻，最终得到所开发的软件产品，投入使用。但实践表明，各个阶段间的关系并非如此简单，由于阶段评审(review)的结果，可能出现向前几个阶段反馈。致使在各阶段间产生环路，无法通过开发活动澄清本来不够确切的软件需求。存在的问题可能导致开发出的软件并不同用户真正需要的软件，更为严重的是在开发过程完成后，才有所警觉。面对这些情况，无疑要进行返工工是不得不在维护中纠正需求的偏差，这些都必须付出高额的代价，并为软件开发带来不必要的损失。
当然，瀑布模型能流行20多年，一则因为它在支持开发结构化软件、控制软件的复杂度，促进软件开发工程化方面起了显著作用；二则因为它为软件开发和维护提供了一种当时较为有效的管理模式。根据这一模式订开发计划、进行成本预算；组织开发人员以阶段评审和文档控制为手段，有效地对整个开发过程进行指导，从而对软件产品的质量有一定程度的保证。对软件公司来讲，后者往往注重不够，没有较为有效地应用。
为弥补瀑布模型的不足，近10年来已经提出了许多其他模型，觉的有演化模型、喷泉模型、螺旋模型、智能模型等等。
（1）演化模型(envoltional model)
软件开发的实践表明，许多开发项目由于人们对软件需求的认识模糊，很难一次开发成功。从而，返工再开发难以避免，因此常常要做两次开发，其产品才能使用满意。干脆第一次作试验开发，其目标只是在于探索可行性，弄清需求；第二次则在此基础上获得较为满意的软件产品。通常我们算第一次试验性产品为原形(prototype)。这样就可减少由于需求不明全开发工作带来的风险，有较好的效果。软件产品的原形有多种形式：
①丢弃型：原型开发后，已获得了更为清晰的需求信息，原型无需保留而废弃；
②演示型：开发原型仅以演示为目的，这往往用在软件产品的用户界面的开发上；
③样品型：原型规模与最终产品相似，只是原型仅供研究用；
④增长式演化型：原型作为最终软件产品的一部分，它可满足用户的部分需求，赴在此基础上开发，则可增加需求，整个实现后交付使用；
⑤粗陋型：用较短时间开发的简易原型。
（2）螺旋模型(spiral model)
将瀑布模型与演化模型相结合，并增加了两者所忽略的风险分析。螺旋模型通常用来指导大型软件项目的开发，它将开发分别划分为制订计划、风险分析、实施开发以及客户评估4类活动，沿着螺线每旋转一圈，表示开发出一个更为完善的新软件版本。如果开发风险过大，开发者和客户均无法接受，项目有可能就此终止；多数情况下，会沿着螺线继续下去，自内向外逐步延伸，最终得到满意的软件产品。
（3）喷泉模型(fountain model)
喷泉一词本身就体现了迭代和无间隙特性。软件的某个部分常常重复工作多次，相关功能在每次迭代中随之加入渐进的软件。无间隙指在开发活动之间无明显边界。喷泉模型主要用于描述采用对象技术的开发过程，
由于对象概念的引入，表达分析、设计、实现等活动只用对象和关系，从而可以较为容易实现活动的重复以及活动之间的无明显“间隙”，使其开发自然地包括重用。
（4）智能模型(intelligent model)
也称基于知识的软件开发模型。它综合了上述若干模型，并得到专家系统的支持。这种开发模型是基于规则的系统，采用归纳和推理机制，帮助软件技术人员完成开发工作，并使维护在系统归约一级进行，为此必须建立知识库，将模型本身、软件工程知识与特定领域的知识分别存入知识库，从而设法构成这一领域软件的开发系统。
据此，我们可以看出任何一软件，一定存在生存周期，而软件的开发可以遵循不同的开发模型，那么，开发模型与开发方法的概念是否一致呢？
软件开发方法是软件开发过程遵循的办法与步骤。软件开发活动的目的是有效地得到一些工作产物，即一个可运行的程序系统及其支持的文档，并且满足质量要求。软件开发方法实际上是指规则、方法和工具的集成，既支持开发也支持维护。那么对软件开发方法有些什么要求？也就是符合什么样的条件才能算得上软件开发方法？在此可以列出一些基本要求：
①应该考虑如下一些因素：
●覆盖开发全过程，并且便于各阶段间的过渡；
●便于各阶段中有关人员之间的通信；
●支持有效的解决问题的技术；
●支持软件设计和开发的各种不同途径；
●支持软件正确性的检验和验证；
●便于在软件需求中列入各种约束；
●支持技术人员的智力劳动；
●接受自动化工具的支持。
②软件开发方法应可教学、可转移。
③对开发过程中各个阶段，应该看得见和可控。
④可容纳新的技术、管理方法和工具，并且与已有的标准相适应。
⑤应具有4个方面的特征：
●技术特征：支持各种技术和概念的方法特色；
●使用特征：使用于具体开发时的有关特色；
●管理特征：增强对软件开发活动管理的能力方面的特色；
●经济特征：给软件公司产生的质量和生产力方面的可见效益。
从这些基本要求来看，在一切方面都好的软件开发方法并不存在，也没有一种方法能适应于所有软件的开发需要。我们通常所使用的软件开发方法以及应用较多的全局性开发方法是结构化开发方法、面向数据结构方法、面向对象方法、形式化开发方法等等。还有一些软件开发方法是专门针对某一阶段的，属于局部性的软件开发方法，如：模块化开发方法就是应用于设计阶段；就不在此作进一步解说了。
一般来说，软件开发方法与软件开发模型并不是一一配对关系，因此，他们并不是同一概念，和软件生存周期也是不同的概念。
在这一节中，我们介绍了这三者的关系，其目的并不在于弄清他们在概念上的区别，而是应该看到人们对于软件质量的重视，想尽各种技术方法来提高软件质量，但由于技术上没有突破，这些技术虽然能提高质量，但人们并不满意，为此只能转向管理方法来继续提高软件质量，而实施ISO 9001标准则是一项有效的方法和途径。
4.软件评审
软件证实是软件开发过程中的一种不可忽视的质量保证手段。它的实质是集中时间，发挥集体的智慧，客观及时地揭示隐蔽的软件缺陷。
●联合评审则是将ISO 9001应用于软件时，供方和需方协商一致的情况下由双方联合进行的。
①管理评审：由最高管理者就质量方针和目标，对质量体系的现状和适应性进行的正式评价。
②合同评审：合同签订前，为了确保质量要求规定得合理、明确并形成文件，且供方能实现，由供方所进行的系统的活动。
③设计评审：为了评价设计满足质量要求的能力，识别问题，若有问题提出解决办法，对设计所作的综合的、有系统的并形成文件的检查。
●设计评审可以在设计过程的任何阶段进行，在任何情况下该过程完成后都进行。
实际上，1976年IBM就开始采用它，取得了很好的效果。后来得到广泛使用，也有许多不同的叫法和不同的组织形式。如inspextion review，walkthough，buddy check等等。
①目的
发现问题（不考虑如何解决），提供开发人员，以利及早地采取措施，消除缺陷。
②组织评审组，由负责人主持整个评审工作
——准备工作，评审组成员聘任、主持评审会。
——评审组成员应包括，开发人员、项目管理人员（配置管理、质量保证人员）、同行专家等。
——人数，5人为宜，不可过多。
③评审会准备
——资料提前5天分发，要求会前准备，阅读并记下问题。
——准备检查表Check List。
——了解准备情况，必要时开预备会。
④评审会
——负责人主持，可由工发人员介绍，也可按检查表逐项进行。
——做记录。
——只讨论问题是否存在，不问原因、责任以及如何解决。
——时间不可过长，防止疲劳低效。
⑤评审会后续事项
——开发组会后根据评审会提出的问题进行修正。
——评审会负责人视情况决定是否再评审，确认修正的有效性。
⑥可能发现的问题
设计错、逻辑错、语法错、标准错、数据错、接口错、返回信息错、注释错、性能错等等。
⑦提高评审效果
——评审活动应规范化。
——评审频度、通过准则等根据评审对象具体确定，区别对待。
——按计划组织评审，不随意变更。
——慎重选聘评审员。
——不具备评审条件时，不急于进行评审。
——将评审分为正式评审和内部评审。
a)内部评审，由软件项目负责人负责，请2~3位专家参加，应在软件开发的每一阶段末进行；
b)正式评审，由上一级技术负责人负责，技术主管部门组织实施，一般在软件任务书形成（所谓功能基线）、软件需求规格说明产生（所谓分配基线）和软件产品形成（所谓产品基线）时刻的评审是正式评审。
二、软件企业实施ISO 9001标准的难点分析
1.质量体系文件
●质量体系文件的建立应在质量策划（见4.2.3）的基础上进行，也可交叉进行。
●除质量手册需统一组织制定外，下层文件最好分别由下属业务归口部门制定，或分别提出方案，再组织审定，以利有效实施。
●质量体系文件并非抛弃企业原有制度与规章，而是在整理、分析原有企业标准、规章制度、管理办法、记录报表后，有所取舍，并按标准要求建立。
●质量体系建立过程是各级管理者和员工进一步理解和学习标准的过程，也是协调管理的过程。
●质量体系文件应根据认识水平的提高、企业各项工作的发展而有所改进和完善，并非固定不变的。
●文件的编制应结合实际、讲求实效，切忌空洞条文。
2.质量策划
●为满足产品、项目或合同规定的要求，供方应考虑以下活动：
——编制质量计划；
——为达到质量要求，配备必要的控制手段、过程、设备、工艺装备、资源和技能；
——确保设计、生产过程、安装、服务、检验和试验（验证）程序和有关文件相容；
——必要时，更新质量控制、检验和试验（验证）技术，包括新的检测设备；
——确定测量要求；
——确定产品的验证；
——确定接收标准；
——确定和准备质量记录（见4.16）
●对于软件，还应考虑：尽可能定量表示质量要求；选定开发周期模型；规定各阶段启动和结束准则；确定验证和确认活动类型；明确配置管理程序。并且注意使质量计划经过所有有关组织评审和协商一致。
3.文件控制
●在与质量体系有关的场合都应使用相识文件的有效版本。
●已作废的文件应及时回收，不论出于何种考虑所保留的已作废文件应对其进行标识和管理，以防止误用。
●文件的收发、复制、归档都应依程序实施，包括编号、责任人员签字等。
●应规定文件的批准权限和批准手续。
●软件配置管理程序体现上述要求。
●在文件控制清单上及时登录最新版本的文件。
●更改文件的性质可直接反映在文件或相应的附录中，可使用不同的字体印刷、更改的部分加底线标记，也可采用“更改页”加以说明。
●文件中一处的更改必须考虑到相关部分所受到的影响，不可遗漏，也要防止一处更改引起的副作用。
●必要时要对文件和资料更改的正确性进行确认。
4.采购
●所谓“采购的产品”，包括硬件、软件、流程性材料和服务以及它们的组合。本要素的控制范围涉及外购件、外协件、分包过程（如设计分包）和服务（如计量服务、检验和试验、运输服务等）。
●在软件开发、供应、安装和维护过程中，采购的产品可包括：市售商品软件；分承包方开发的软件；计算机和通信硬件；辅助软件开发的工具；承包工作人员；维护和顾客的支持服务；培训课程和教材。
●取得分承包方能力信息的途径可以是问卷调查、现场考察等，但这些活动应有具备必要专业知识的人员参加。
●分承包方经评价合格后，应定期对其业绩进行监督，方式可以是签订质量保证协议，签订带有质量保证内容的合同或进行定期的审核等。
●当分承包方出现不合格时，应考虑是否需要对分承包方采取措施，例如提出警告、责令采取纠正措施、从合格分承包方名录中剔除。
●当某些产品只有惟一的一家分承包方，其质量又不太稳定时，应注意加强进货检验和试验，或采取其他必要的措施。
●如果是通过电话或口头给出采购规范，应将其写入采购文件，如采购计划或采购清单。
●供方若有提交样品或使用特殊的包装要求，这些也应在采购文件中标明。
●参照合同评审方法对分合同进行评审。
5.标识
●建立配置管理程序，对软件项的标识应包括：文档、源代码、目标代码和可执行代码、重用软件、外购软件、顾客提供的软件、有关的开发工具、与其他软件项及硬件的接口、硬件环境和软件环境等，标识软件产品的构成状态；控制多人同时对同一软件项的更新和所有的更改措施；及时报告配置状态；确保文实相符、文文一致。
●标识产品的方法应与所标识的产品相适应，例如，可以是投料、投料时间、不同的颜色等，也可使用伴随文件的方法，可用印章、标签印刷将编号附在包装上，也可直接标识在产品上。
●应正确处理可能发生的标识转移和丢失，确保产品标识正确和实现可追溯性。
●保存可追溯性的记录。
●标识用的印章、标签、涂色剂等均应规定使用管理办法和相应人员的责任。
●按软件配置管理的各项程序进行。
●检验和试验状态标识方法可随产品不同而异，例如：彩色标记、贴在道路 的标签、跟随产品的检验记录和区域标识等。
●当发生标识转移时，应确保转移的正确性。
●当出现丢失状态标识情况时，应作妥善处理，慎重判定当前状态，一般应作为待在一起。
●软件的审查和测试记录可纳入配置管理，按配置管理方法标识有关状态，否则应有单独规定的标识方法。
6.服务控制
●过程控制不仅指过程处于受控状态所采用的控制技术或活动，还应确定哪些是直接影响质量的生产、安装和服务的过程，进而制定并实施控制计划，保证之些过程处于受控状态，使产品质量达到合同规定的要求。
●受控状态是指对影响过程质量的所有因素，包括工艺参数、人员、设备、材料、加工和测试方法、环境等加以控制。
●上述要点中第3条指明的是一种特殊过程，即过程的某些加工质量不易或不能通过其后的检验或试验而充分得到验证，例如焊接、热处理、表面处理、铸造、粘接等。
●对于软件，要考虑其开发、复制、交付和安装等过程活动的控制。
●建立软件复制程序。
●建立软件发行、交付和安装程序。
●软件配置管理程序应考虑这些过程活动时的控制。
●对于有安全、保安要求的软件，进行定量方法。
7.不合格品的控制
●软件开发过程的成品如果不符合规定的需求，必须进行修改。仅当验证合格，才能将软件交付或发行，复制过程产生的不合格品一般是软件和其载体一起不合格。
●返工或返修后的产品都应按质量计划或程序文件重新检验和确认，并应保存记录。
●使用返修的不合格品应建立和遵循向顾客通报的制度。
●软件的修改应执行配置管理程序，特别注意修改影响分析和回归测试。
●对于软件，不符合要求就要修改，进行相应的变更控制。
8.纠正和预防措施
●当所采取的纠正措施无效时，应重新开始采取纠正措施。
●当他承包方提供的产品存在问题时，应采取一定的纠正措施，直到更换分承包方。
●规定调查产品不合格产生原因的方法。
●对纠正措施进行跟踪，确认纠正措施的有效性。
●纠正措施配合管理评审实施。
●明确采取纠正措施的时机。
●实施软件问题解决过程。
●执行软件配置更动程序。
●采取预防要比纠正措施更困难，为分析和确认不合格的潜在根源，常常使用统计技术，但应注意评审其适用性。
●多数情况下，定期进行分析，确保采取的预防措施是有效的。
●有计划地持续改进软件过程。
9.质量记录的控制
●应采取措施确保质量记录的安全性，特别是电子媒体的质量记录不被任意篡改、删除、并且免遭计算机病毒、外界磁场、环境潮湿、雷击等因素而损坏。
●用电子媒体保存质量记录时，应考虑防护信息改变和方便使用的措施。
●可以参考软件配置管理方法或与之结合。
10.内部质量审核
●内部质量审核的频次和日程安排可根据具体情况决定，但两次审核的间隔不宜过长，一般可在12个月之内。
●内部质量审核人员应经过培训，取得资格。
●内部质量审核可分四个阶段进行，即准备、实施、报告和跟踪。工作量投入大致为4∶4∶1∶1，在准备阶段最好进行审核策划，包括制定计划、组建审核组、编制审核检查表，并作文件审查。
●在实施审核阶段可采取检查表、随机抽样、发现不合格再进行进一步审核等的方法。
●根据实际情况，可考虑聘请外部人员参与内部质量审核。
●应确定判断质量体系有效性准则，例如包括：不符合的程度、质量目标的实现等。
●开发多个软件项目时，可通过生存周期的不同阶段审核若干项目来逐步覆盖整个质量体系。
11.数据统计和分析
●应用统计技术可能对质量控制有指导作用的场合有：
质量目标、管理评审、设计控制、过程控制、检验和试验、预防措施。
●可酌情选用某些统计技术和统计工具，如：因果图、直方图、柏位图、散布图、控制图、系统图、方差分析、抽样检验等。
●应考虑统计数据的采集、分析与计算及统计结果的表达。
●可用统计技术的软件产品特性：可测试性、易用性、可靠性、可维护性和可用性。
●可用统计技术的软件过程能力特性：过程成熟度、过程输出中的缺陷类型和数目、缺陷清除效率和重大的能力下降。
12.产品交付和防护
●在软件配置管理程序中明确规定防护方法，如：
——定期备份；
——及时复制到可替换的媒体上；
——软件媒体存储在受保护的环境中；
——软件媒体还存放在备用的环境中，以确保受损后的恢复。
●在搬运操作中应考虑防止振动、撞击、腐蚀、人手接触、阳光、电磁等对产品的影响。
●对于软件在开发过程中应及时杀灭病毒；防止误码；预防载体损坏或变质。
IP卡
狗仔卡
发表于 2010-2-10 10:15:03
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
显身卡
