软件企业建立质量体系应注意的几个问题.doc

软件企业建立质量体系应注意的一些问题（一）CANT注册高级审核员QuEST Forum论坛 注册TL9000审核员 袁伦成软件产品的实现与硬件产品的实现过程在质量管理方面有很大的差异。在按照ISO9000：2000质量管理体系 要求标准建立质量管理体系时，应根据其产品特性注意以下问题：一、 建立质量管理体系应依据的主要准则和要求：软件企业建立质量管理体系主要依据的准则是GB/T19001-2000质量管理体系 要求标准或TL9000 R3.0质量管理体系 要求手册和质量管理体系 测量手册。但同时还应满足以下技术标准和规范：GB/T19000.3-1997 ISO 9000-3-97 GB/T19001-ISO9001 质量保证标准 在计算机软件开发、供应、安装和维护中的应用指南；以及下列软件专业基础、过程、质量、技术与管理、工具方法、数据标准和规范：专业基础：GB/T11457-1995 软件工程术语GB/T13702-1992 计算机软件分类与代码GB/T15538-1995 软件工程标准分类软件过程：GB/T 85662001信息技术软件生存周期过程GB/T 8567-1988 计算机软件产品开发文件编制指南GB/T93851988idt IEEE 830:1984 计算机软件需求说明编制指南GB/T93861988idt IEEE 829:1983 计算机软件测试文件编制规范GB/T12505-1990 计算机软件配置管理计划规范GB/T155321995计算机软件单元测试GB/T140791993软件维护指南GB/T166801996软件文档管理指南GB/T 85662001信息技术软件生存周期指南软件质量：GB/T 12504-1990计算机软件质量保证计划规范GB/T17544-1998 信息技术 软件包 质量需求合测试GB/T18491.1- 2001信息技术 软件测量 功能规模测量 第一部分 概念定义GB/T18492-2001 信息技术 系统文件完整性级别技术管理：GB/T 134231992工业控制用软件评定准则GB/T 143941993计算机软件可靠性可维护性管理GB/T162601996 idt ISO/IEC 9126:1991 信息技术 软件产品评价 质量特性及其使用指南GB/T18905.1-2002 软件工程 产品评价 第一部分 概述GB/T18905.2-2002 软件工程 产品评价 第二部分 策划和管理GB/T18905.3-2002 软件工程 产品评价 第三部分 开发者的过程GB/T18905.4-2002 软件工程 产品评价 第四部分 需方用的过程GB/T18905.5-2002 软件工程 产品评价 第五部分 评价者用的过程GB/T18905.6-2002 软件工程 产品评价 第六部分 评价模块的文档编制工具与方法：GB/T15853-1995软件支持环境GB/T18914-2002信息技术 软件工程 CASE工具的采用指南GB/T18234-2000信息技术CASE工具的评价与选择指南数据： GB/T1526-1998 信息处理 数据流程图、程序流程图、 系统流程图、程序网络和系统资源图的文件编制符号及约定GB/T13502-1992信息处理系统 计算机系统配置图符合及约定GB/T15535-1995信息处理 单命中判定GB/T15697-1995信息处理 按记录组处理顺序文卷的程序流程质量管理体系：GB/T19001-2000 idt ISO 9001:2000 质量管理体系 要求GB/T 19004-2000 idt ISO 9004:2000质量管理体系-业绩改进指南GB/T 19000.3-1997 ISO 9000-3-97 GB/T19001-ISO9001 质量保证标准 在计算机软件开发、供应、安装和维护中的应用指南行业标准规定：信息产业部文件 信部规19991047号计算机信息系统集成资质管理办法（试行）信息产业部文件 信部规2003 440号文计算机信息系统集成资质等级评定条件（修订）2000年10月16日信息产业部、教育部、科学技术部、国家税务总局软件企业认定标准及管理办法（试行）SJ/T30003-93电子计算机机房施工及验收规范GB 2887-89 计算机场地技术条件GB 9361-88 计算机场地安全要求GB/T50314-2000智能建筑设计标准GBJ/T 50311-2000 建筑与建筑群综合布线工程系统设计规范GBT/T 50312-2000 建筑与建筑群综合布线系统工程验收规范上述准则并不是全部，仅以为例。应注意保持所建立的质量体系与上述标准、规范的符合性。二、按照ISO9001：2000标准的 4.1总要求的规定，应识别软件设计、开发、安装及计算机系统集成服务的实现过程，这些过程与硬件产品的实现过程有较明显的区别。体现在以下几方面：（一）研制过程不同- 软件计算机软件是一种以逻辑实体形式存在的信息产品。经确认并实现的软件产品的本身始终不会自然变化，只是其载体可变：如计算机硬盘、软盘、MO磁光盘、CDRW、CDR可刻录光盘或磁带等。与硬件相比具有以下特点：1、软件产品的研制过程主要依靠开发者利用适宜的开发工具的一系列智力劳动的过程。其可见性差，难以测量，产品的缺陷和不可靠问题基本上是人为差错。为此，应对软件的设计开发人员进行经常性的培训、教育，提高开发技能和水平。保证开发所需的基础设施、工作环境、计算机软件、硬件应与开发项目要求相适宜。 但这一点，因软件业存在人员频繁流动，员工新旧更替相对比较频繁的特点，新员工未经规范性系统培训的开发习惯及人员之间的沟通问题可能导致产品质量控制不能到具体的人，使这种人为差错难以规避。没有前兆；并2、软件研制的工作量大都集中在计划和开发阶段。没有明显的生产制造过程，其生产和制造过程即是软件产品的复制、包装、安装、交付和交付后的维护（补丁、升级）活动。因此： 软件的设计与开发过程往往密不可分；产品的开发与实现过程往往密不不可分；开发输出的验证和确认过程与产品的监视和测量过程往往密不分。这三个密不可分可导致在质量管理体系的策划中往往把软件产品的设计验证和确认活动与过程监视测量和产品的监视测量作为同一过程来策划和实施。3、软件之间存在一定的耦合，耦合的不正确性可能导致缺陷。 软件之间的耦和可分为：内容耦合、公共耦合、外部耦合、控制耦合、标记耦合、数据耦合、非直接耦合七种耦合。是对模块之间相对独立性的量度，也称为块间联系。软件之间的耦合亦可称为开发各环节的接口，它不易保证其正确性。这种偶合的不正确性可能导致“软件缺陷”。它是程序内部不合理的逻辑结构、不正确的语句和不适当的指令所引起的。又由于软件系统模型的离散性，输入微小变化可能引起输出的巨大变化，在前阶段出现的缺陷，可能残留，并在后续阶段被放大。据统计，如软件概要设计中出现的缺陷残留，在详细设计阶段可能放大到1.5倍，而在产品的实现阶段，缺陷的放大系数甚至达到3。这种情况可能导致一个程序的修改会影响其他模块。因此，程序修改后，必须进行回归测试。但另一方面，软件缺陷的存在并不一定会引起程序不能运行。只有当程序中的缺陷被执行时，故障才会发生。故障的形成无物理原因，失效发生取决于输入值和运行状态的组合。所以，一旦程序出了故障，其中必定隐藏着相应的缺陷。 4、软件产品应在其整个“生命活动周期”内都实施配置管理，保证对其开发过程和交付后的维护支持过程中的各种变化的“标识和可追溯性”。软件的交付后维护支持过程包括修改设计、增加补丁及补丁程序以及增加软件功能。任何软件都不可能逾越这一阶段。除非该软件已经到了生命的结束期，即软件产品的终止期。 5、由于大多数软件产品孤立性（单个开发，不能形成批量销售的产品 ），导致对其控制要求存在很大的差异。主要来自于以下方面：u 软件的研制过程模型不同：瀑布模型或原型开发模型。u 嵌入式软件或非嵌入式：多用汇编语言编写的嵌入式软件与硬件联系紧密；实时性要求高；有严格的时序；要求具有高可靠性、安全性、更能抵抗恶劣环境。u 开发工具的应用程度；不同的软件可能采用手工开发或采用开发工具、管理工具和测试工具开发两种开发方式。手工开发难于避免出现差错。u 软件关键性等级；一般分为A、B、C、D四级。等级越高控制要求越高。u 软件的规模；对源代码行数小于5000的非嵌入式软件和源代码行数小于3000的嵌入式软件，可视为小型软件，控制要求相对弱些。6、软件测试技术具有局限性，尤其是不少小型软件组织和小规模软件。7、软件质量指标许多尚未量化，也难已量化；8、软件（客户）的需求不定性及软件技术的快速发展，使软件产品不可能绝对无缺陷才释放发布。软件产品始终处于需要不断更新的状况。软件（客户）的需求不定性使软件开发初期阶段不能真正反映用户意图。而确定需求是非常重要的工作，它既是后继阶段开发的基础，又是完成后验收的依据，并且还是工期和开发成本估计的出发点。- 硬件1、硬件产品是物理实体。每件同规格产品之间都有散差，会随时间和使用而老化、磨损，以至失效；2、生产和服务提供过程是人力劳动和机具设备的加工过程，过程有形，便于测控；3、除了设计原因外，产品（或零、部件）在生产和使用过程中都会产生故障；4、故障总是由组成产品的零、部件或其结合的故障引起；5、系统故障的形成和失效一般都是物理原因，有前兆。（二）可维护性和可靠性工程不同- 软件软件维护阶段的关键任务是通过各种必要的维护活动使系统持续满足用户需要。 通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。前三种维护是在用户提出请求后由维护人员完成的。预防性维护对那些生命周期较长，但需作重大修改、完善功能的软件进行的可靠性或可维护性改善。据有关资料统计各种维护活动的分布如图：改正性维护20%；适应性维护25%；完善性维护50%；预防性维护5%可靠性（Reliability）是软件的一项重要指标。它指的“在规定的条件下和规定的时间内，计算机完成规定功能（无故障运行）的概率”。为了提高其可靠性，需要注意以下几方面：1、 研究的对象：应考虑软件与一般的系统或产品不同的特有的一些性质；2、 规定的功能、故障和缺陷的含义；3、 规定软件的工作环境和使用环境：不同的环境，软件发生故障和暴露缺陷的可能性有很大差距；4、 规定的时间：泛指的广义时间。如因对象的不同遇到的次数、周期、距离等时间的量。此外，还有连续使用、间歇使用、放置、长时间、短时间、瞬间等各种时间概念。- 硬件1、产品的可维护性和可靠性往往在设计开发过程中已经确定。可靠性参数有物理基础。生产过程对产品的可靠性影响也很大，应加强控制；2、产品的生产需要建立环境应力条件，通过对零、部件的筛选，排除故障；3、相同的部件之间是自然独立的，在可靠性设计中采用适当的冗余可以提高其可靠性；4、使用过程中出现产品故障，只需通过维护活动更换或修复失效部件即可使产品恢复良好状态，但可靠性一般不会因此提高；5、维修一处一般不会对它处造成影响；6、失效率变化类似浴盆曲线；（三）生成活动周期阶段及其过程不同1、典型的软件的生存活动周期阶段划分（Life Cycle Mode生命周期模式） 维护和增强验收测试确认测试系统验证测试系统需求系统联试软件需求分析配置项配置项组装测试软件概要设计部件部件软件详细设计单元测试单元单元单元单元编码 上图1实际上把软件的生命活动周期过程（LCM）划分成为5个阶段:1)需求分析（Requirement Analysis）;2)设计（Design）;3)程序编写（Coding）;4)测试（Testing）;5)运行和维护（Run and Maintenance）;每个阶段都有确定的任务，并生成一定规格的文档交送给下一个阶段。见表1。表1 软件工程各阶段的基本情况阶段基本任务工作结果占开发期的工作量参加者开发期需求分析理解和表达用户要求，详细定义系统说明书20%用户、高级程序员设计建立系统结构模块说明书数据说明书15%高级程序员程序编写编写程序程序20%高、初级程序员测试发现错误和排除错误可运行系统45%（模块测试25%其他测试20%）评测部门运行运行和维护期维护改进的系统用户、程序员需要说明的是：并非所有的软件开发都必需经过上述各个阶段。在实际的开发活动中，可根据所开发软件的规模大小，允许对某些阶段进行合并或“删减”。具体的合并或“删减”可通过对软件产品的形成过程进行分析，在策划阶段来决定。应策划软件工程的各个过程活动。主要活动如下：指明工作环境：指明影响“删减”的工作环境特征；收集信息：向所有可能会影响“删减”的组织和个人收集信息；选取过程、活动和任务：根据收集到的信息，确定要实施的过程活动和任务；编制文件：将所有的“删减”决策和作出这些决策的理由按ISO9000；2000标准要求将其写入质量管理体系文件，明确体系的覆盖范围。“删减”可分为两级：第一级，根据组织提供产品的不同应用领域进行“删减”；第二级，根据组织所提供的每个具体的项目或合同进行“删减”。 “删减”只能是对ISO9000：2000标准1.2 规定的允许删减的第7章的要求。“删减”不应影响组织提供产品满足顾客和法律法规要求的 能力和责任。2、通用（硬件）产品的生成周期阶段概念和定义设计和开发制造和安装使用和维护处理三、软件产品的实现过程识别：软件工程的规范规定：产品（软件）的实现过程是围绕着产品的“生命活动周期”进行的。产品“生命活动周期”是如前图1所述的从一个产品（软件）的“点子、需求分析、软件概要设计、详细设计、编码、产品测试、确认、验收、软件释放、维护和增强、产品终止”的各个里程碑的PDCA循环全过程。应根据上述过程策划软件产品的设计、开发、实现、交付、维护和持续改进的全过程。软件生命活动周期的各个过程及其相互关系如下图2：它描述了这些过程之间的关系，软件企业的质量管理体系应紧紧围绕这五个阶段去建立和保持。软件生命活动周期过程组织过程支持过程基本过程文挡编制过程配置管理过程质量保证过程维护过程供应过程开发运行过程获取过程审核过程联合评审过程确认过程验证过程改进过程基础设施的维护过程管理过程培训过程问题解决过程图2上述各个过程与ISO9000：2000标准的各条要求的关系可能如下表：过程标准要求过程标准要求过程标准要求获取过程5.2,7.2,(8.4)(7.4.3),(8.2.1)供应过程7.4,(8.2.3)(8.2.4)审核过程5.6, 8.2.2文档编制过程4.1,4.27.1a)b),7.5.1a)联合评审过程5.6,7.3.4,(7.2.1),7.2.2(7.2.3),8.2.2问题解决过程8.3,8.5.2,8.5.3基础设施维护过程6.1,6.36.4,7.5.1c)改进过程(5.6.3),8.5培训过程6.2,7.5.2开发过程7.1,7.3,(7.2.3),(7.4.3)(8.2.1),(8.5)质量保证过程5.3,5.4.1,6.17.1,7.2.2,7.37.4,7.5,7.6,8.18.2.3,8.2.4,8.5管理过程4.1,5.1,5.3,5.45.5.1,5.5.2,5.5.35.6,8.4,8.5验证过程7.3.5,7.4.38.2.4配置管理过程(7.3),7.5.3(7.6)维护过程7.5.1f)(8.2.1),(8.5.1)确认过程7.3.6,(7.2.3)(8.2.1),8.2.38.2.4 从表中反映的上述各个过程与GB/T19001-2000标准4.1注中所述的“质量管理体系所需的过程应当包括与管理活动、资源提供、产品实现和测量有关的过程”这一通常的要求是完全相符的。可以非常清楚地看出：对“软件生命活动周期的各个过程”覆盖了ISO9001：2000标准的全部要求，对其控制有效，则表现出组织建立的 ISO9001：2000质量体系运行有效。 此外，GB/T19001-2000标准的4.1“总要求”规定：“组织的最高管理者应识别产品（软件）的实现过程，同时应识别产品的外包过程”。软件产品实现过程中可能的外包过程有：软件模块的委外开发、系统质量指标的委外评测等。应对这些外包过程加以识别，并在相关的过程，如“采购过程”中加有效控制。软件企业建立质量体系应注意的一些问题（二）对与软件产品实现过程有关的GB/T19001标准的主要过程要求的理解和认识：通常，软件企业按照GB/T19001-2000标准建立质量管理体系，应满足标准的全部要求，即不允许任何删减。但对与软件产品实现过程特性相关的几个质量管理过程要求，如：4.2.3,5.4.1,5.4.2,5.5.3,6.2.2,6.3,6.4,7.1,7.2,7.3,7.4,7.5,7.6,8.2.3,8.2.4,8.3,8.5应加以尤其的理解和重视。所建立的质量管理体系要充分、控制要有效、提供的运行有效的证据应与软件产品的专业特性相适应、保证符合前述的各个准则要求。以下简介相关过程要求的理解和控制要点。1、4.2.3“文件控制要求”：按照GB/T8567-1988 计算机软件产品开发文件编制指南的规定，计算机软件开发过程中会形成多达13种文挡。含：管理文档、开发文档、用户文档。而这些文挡大部分是以“电子文挡”形式完成的，应注意对它们的控制，并在GB/T19001-2000标准要求必须文件化的文件控制程序和设计和开发过程控制程序中，明确地规定它们在软件的“生命活动周期”内的生成阶段（表1）和控制要点。这是因为，在线和基于Web的“电子文挡”太容易被变更，而且因为它们的内在的易变性更容易被怀疑。应明确对这类文档的控制要点，规定控制方法并实施有效控制。包括：采用适当的工具和环境支持变更管理，审计跟踪、电子签名和其他群件，对文挡的编制、发布、访问、COPY、备份、存档、防护等，以保证文挡的充分性、有效性、适宜性、完整性和安全性，最终取代纸质文档。1.1 软件开发过程的13种文档： 表1三种文档用户文档1用户手册2操作手册开发文档3项目开发计划4可行性研究报告5软件需求（规格）说明书6数据要求说明书7概要设计说明书8详细设计说明书9维护修改建议管理文档10测试计划11测试报告12开发进度月报13开发总结报告对于嵌入式软件，设计文挡可以单独形成，也可以包含在一个由硬件和软件集成的系统或产品的文件中。软件的开发策划可与系统或产品的设计策划一并进行，软件的规格说明可以系统的需求形式提供，但应确保系统需求正确地分配到软件及适当的接口说明中。1.2 13种文挡的生成阶段（表2）： 软件的生命活动周期内各阶段生成的文档 （表2）阶段文档可行性研究与计划需求分析设计代码编写测试运行与维护可行性研究报告项目开发计划软件需求说明数据要求说明概要设计说明详细设计说明测试计划用户手册操作手册测试分析报告开发进度月报项目开发总结维护修改建议2，4.2.4记录控制：计算机业的质量体系运行记录，是用于证实组织有效运行体系，并取得绩效的证据。其示例有:测试结果;问题报告;更改请求;带注释的文档;评审记录;会议记录;审核报告。所有的记录应清晰,保管方式应便于存取和检索,保管设施应提供适宜的环境,以防止损坏、变质和丢失。应规定并记录质量记录的保存期。合同要求时,在商定期内质量记录可提供给顾客或其代表评价时查阅。记录可以呈任何媒体形式,如硬拷贝或电子媒体。当记录保存在电子媒体中时,考虑保存时间和记录的可访问性时应考虑到电子图像的退化速率,以及为访问记录所需的设备和软件的可用性。3，5.4.1“质量目标”：软件业的质量目标的建立和确定应依据GB/T 19000.3-1997 ISO 9000-3-97 GB/T19001-ISO9001 质量保证标准 在计算机软件开发、供应、安装和维护中的应用指南，GB/T 12504-1990 计算机软件质量保证计划规范和GB/T162601996 idt ISO/IEC 9126:1991 信息技术 软件产品评价 质量特性及其使用指南的规定，建立和确定企业的“质量目标”。按照GB/T19001-2000标准要求，所建立的质量目标应是“可测量的”，并能分解到企业的各个管理层次，与企业的质量方针保持一致。此处“可测量的”意思是指 “可度量”和“可感知”两个方面。因此，参照GB/T 16260-1996 idt ISO/IEC 9126:1991 信息技术 软件产品评价 质量特性及其使用指南的规定和TL9000 R3.0质量管理体系 要求手册和质量管理体系 测量手册中有关软件产品的测量指标要求， “可度量”的概念讲，应包含：（1） 软件的系统中断（SO）：指对计算机系统集成的全部或部分功能性完全丧失的度量。以一个平均系统的全部年度数字（中断频率）和全部中断周期（停工）。可直接转换为系统平均失效间隔时间（MTBF）和系统的可用性。平均失效间隔时间( MTBF )= 平均失败时间（MTTF）+ 平均修复时间MTTR或MTBF=（365）*（24）/OF，其中：OF=12*中断数量/月底在用系统的数量。系统的可用性：指在规定的时间点上程序能够按照需求执行的概率。可用性=MTTF/（MTTF+MTTR）* 100%（2） 软件的可度量的质量目标：如软件产品的缺陷率。可以用“每千行代码的缺陷数量”来定义，并按照缺陷的严重程度或功能性影响进行度量。没有那一个软件是十全十美的，任何软件都有缺陷，只是你还没有发现。因此，为消除缺陷，开发者采取了很多措施（如，打补丁），但如何知道所采用措施是否有效？看CPQ 、FPQ和 SWU三个指标。 CPQ即“补丁 软件缺陷纠正质量”。CPQ指标表征了某一版本软件纠正缺陷所采用措施的有效性。CPQ值越高，表示措施越有效。被确定为有缺陷的正式纠正补丁的百分比 =( 版本为N的产品本月缺陷纠正补丁总数量 / 版本为N的产品本月成为通用版本可用的纠正补丁总数量 )X 100% FPQ即“补丁 功能缺陷纠正质量”被确定为有功能缺陷的正式功能补丁的百分比 = ( 版本为N的产品本月缺陷功能补丁总数量 / 版本为N的产品本月成为通用版本可用的功能补丁总数量 ) * 100%【注：补丁计算应根据软件发出之日起的可用时间按月计算产品的三个主要版本。包括：一个单元中包含在一起的不相同的补丁，在一个系统中的同样的补丁，分散提供的影响不同部分的代码的补丁，包含在版本内的需要额外努力实施的补丁。】 SWU即“软件的更新质量”该指标是评估有缺陷的软件的更新级别，以减低顾客风险。评估必须按月计算，并包括产品的最主要的三个版本。SWU =( 版本N的缺陷软件更新的累计数 / 版本N的软件更新的累计数 )*100% （3） 软件的服务目标（SQ）和子指标可包括：S1：安装服务量；S2：维护服务量；S3：返修服务量；S4：呼叫服务量；S5：支持服务量；Sd1:安装/或工程不合格数；Sd2：维护回收数；Sd3：缺陷维修保证单元数；Sd4：客服中心超过特定协议规定的时间，按时提出解决方案数量；Sd5：支持服务的缺陷数；各项服务产品类别的服务质量指标，缺陷数量、服务交付量定义如下表1：服务类别计算的项目（缺陷）服务交付量（缩写）%SQ安 装不一致审核数量 总安装审核数量（审核数量）%SQ维 护回收数量 总维护调查数量（调查数量）%SQ维 修缺陷维修保证单元数量 总维修单元数量（维修数量）%SQ客户支持服务客服中心超过特定协议规定的时间按时提出解决方案数量 总呼叫数量（呼叫数量）%SQ支持服务缺陷数量 总处理数量（处理数量）%SQ服务质量（SQ）测量标识符和计算公式：SQ1（安装/或工程合格）= （1- Sd1/S1）X 100%审查合格SQ2（成功维护调查）=（1- Sd2/ S2）X 100% 调查无回收SQ3（成功维修）=（1- Sd3/ S3）X 100% 成功维修SQ4（合格呼叫中心）=（1- Sd4/ S4）X 100%协议时间内准时解决SQ5（合格顾客支持服务）=（1- Sd5/ S5）X 100% 无缺陷处理而“可感知”的质量目标至少应包括GB/T162601996 idt ISO/IEC 9126:1991 信息技术 软件产品评价 质量特性及其使用指南中要求的软件产品的六个质量特性指标： 功用性（Functionality），即软件是否满足了客户功能要求； 可靠性（Reliability），即软件是否能够一直在一个稳定的状态上满足可用性； 可用性（Usability），即衡量用户能够使用软件需要多大的努力； 效 率（Efficiency），即衡量软件正常运行需要耗费多少物理资源； 可维护性（Maintainability）,即衡量对已完成的软件进行调整还需多大的努力； 可移植性（Portability），即衡量软件是否能够方便地部署到不同的运行环境中。4，5.4.2“质量体系策划”：应注意软件产品的重大变更、软件开发团队的重大变更如何保持质量体系的完整性。5，5.5.3“内部沟通”：计算机软件企业的内部沟通具有非常好的技术平台，即Internet或Intranet计算机网络的互联互通。通常采用公司内部的办公自动化网络来实现沟通。在建立质量体系时可考虑充分利用这种网络资源，规定以包括：文件处理流程、网络通知、Email等等在内的电子类文件实现这些沟通并保持记录（证据）。6，6.2.2人力资源控制：软件产品的开发和实现过程是依靠具有专门技能的人员（系统分析员、程序员、高级程序员）使用计算机软件、硬件等开发工具的智力创造过程。因此，对人员的能力确定和资格的认定非常重要。应在公司的人员能力要求或岗位任职要求中参照信息产业部文件软件企业认定标准中的规定，对软件项目的开发人员，管理人员作出适宜的规定和确定。同时，应注意收集和保持这些人员的经历、经验和资格的证据（证书）。由于计算机软件技术的日新月异的飞速发展，对这些人员应提供技能和知识更新的机会，应向这些人员告知和提供培训的机会。以保证软件产品的开发和实现过程的控制有效性。7，6.3“基础设施控制” ：在软件产品实现过程中的基础设施，与制造业中的硬件产品实现过程所需的基础设施有很大的不同。在此处，没有机床设备，只有用于产品开发的计算机网络设施、PC工作站、第三方的操作系统软件、组织本体开发的或第三方的开发工具软件、数据库软件、配套的电源支持系统等等硬、软件设施。应按照标准要求，进行识别，并加以维护控制，保持满足产品要求的能力。8，6.4“工作环境”：由于计算机软件产品是开发者依靠计算机硬件的智力劳动和创造性劳动的实现特征。组织的最高管理者应提供一个既能满足计算机硬件设备可靠运行要求，又能使开发者充分发挥其智力和创造力的环境。并加以保持。9，7.1“产品实现的策划”：在获得产品信息后，组织应按标准要求对软件产品的实现进行带有专业特点的策划。策划的内容应包括项目的可行性研究、实现方法、开发团队组织、测试验证方案、产品成果的接受准则、项目管理策划（人员、进度安排）、使用的开发工具、硬件开发平台、网络运行环境、与其他软件的兼容性、接口以及设计策划、编程、单元测试、系统测试、确认测试、验收测试、软件复制、交付和后续安装维护等等。策划的结果应形成以下文件：可行性研究报告、投标书、项目开发计划、项目方案的策划书、新产品介绍计划、质量计划或项目开发计划、产品生命周期指南、产品生命周期结束策划、试验策划及计划、集成计划、转换计划、安装计划、移交计划、重用计划等文件。以下简介产品实现策划结果文挡应包含的基本内容9.1“新产品介绍计划”：质量和可靠性预测研究、样件生产、要求和产量研究、销售和服务人员培训及新产品引入后的评价。9.2 一个“质量计划”或“项目开发计划”的默认大纲：1) 项目的可行性；2) 项目的质量目标和要求；3) 项目的作用和职责；4) 项目的组织结构和人力资源（组织、与内部和外部的组织接口、人员结构计划和项目专有的培训要求和计划）；5) 产品的生命周期阶段划分、工作流程、检查点；a) 主里程碑的范围和内容；b) 次里程碑的范围和内容；c) 过程改进规程；6) 软件工程环境：a) 过程自动化（硬件和软件资源配置，用于支持开发的非交付软件的控制方法；b) 资源分配规程（跨组织的共享，安全访问）；c) 标准、规则、惯例和约定；d) 开发用的工具和技术。包括对这类工具和技术的鉴定和技术状态控制；7) 软件评估和管理：a) 度量元采集和报告规程；b) 软件变更管理：配置管理惯例及计划；软件变更定义和规程；配置基线定义和规程；c) 风险管理（风险管理规程和应急计划-如在技术、成本及进度方面、标识、追踪和解决）；d) 涉及的有关计划（例如，开发计划、质量保证计划、测试计划、验收计划、状态评估计划、验收测试计划）；e) 项目跟踪、控制不合格品和问题（缺陷）的解决方法及提出报告的方法；8) 准备使用的方法、确认、监控和产品的验收标准或规程、形成文件的程序文件及工具；9) 在产品的生命周期中，顾客及供方的参与（如，联合评审、非正式会议及批准）；10) 绩效、安全、保安及其他关键的要求；11) 备份和恢复(包括应付偶然事故的计划)的规程；归档、备份和恢复的程序,包括应急计划；病毒防护的控制方法；12) 要求的认证；专利权、使用权、所有权、保证期及特许权；13) 与项目活动有关的预算报告；根据产品的复杂程度，计划内容可能是全部或必要的一部分。项目开发计划和任何有关计划可以是一个独立的文件或另一个文件的一部分或几个文件的组合。对所有开发项目都通用的、规定任务和职责的通用作业指导书，不需要重复地作为“项目开发计划”的一部分。9.3试验策划计划的大纲：1) 试验范围（例如，单件、特征、集成、系统、验收）；2) 需要完成的试验类型（例如，功能试验，边界条件试验、可用性试验、性能试验、回归试验、相互可操作性试验）；3) 对要求的可追溯性；4) 试验环境（例如，相关顾客环境、操作使用）；5) 试验覆盖范围（试验验证产品功能的程度，有时以新试验功能的百分比表示）；6) 预期结果；7) 数据定义及数据库要求；8) 试验设定，试验情况（输入、输出、试验准则）及形成文件的试验程序；9) 外部试验的使用；10) 报告和解决缺陷的方法。9.4 “集成计划”应文件化。用于将各软件组件集成到产品中（如公司有嵌入软件的EDA实验系统产品），去确保它们按设计相互作用。这些计划必须包括：1) 方法和形成文件的程序；2) 职责；3) 集成进度；4) 试验要求。9.5 当一个系统，或软件产品从一个旧环境转换到一个新环境去时，必须制订一个文件化的“转换计划”。该计划应包括：1) 转换的要求分析和定义；2) 转换工具的开发；3) 产品和数据的转换；4) 转换的执行；5) 转换的验证；6) 未来对环境的支持。9.6 通过策划还应建立并保持以下方法和计划：a) 软件产品的灾害恢复方法灾害恢复方法可参照GB/T85661995 （ISO/IEC 12207）信息技术软件生存期过程编制。b) 软件产品的技术状态（配置）管理计划， 内容可包括：- 技术状态（配置）活动的标识和范围；- 完成这些活动的进度；- 技术状态的管理工具；- 技术状态的管理方法和形成文件的程序；- 委派给他们的组织和职责；- 每一个技术状态需要的控制水平；- 将各个项目置于技术状态管理下的起始点（里程碑）。c) 估算方法：建立并保持一个在项目策划、实施和变更管理时用来估算和追踪项目参数的方法。需考虑的项目因数应包括产品规模、复杂性、作出的努力、人员配备、进度、成本、质量、可靠性和生产力。 d) 计算机资源：建立并保持用于为目标计算机估算和追踪关键性的计算机资源的方法。这些资源可包括如存储器的利用、吞吐量、实时性能及I