软件企业建立质量体系应注意的几个问题新Word下载.doc
《软件企业建立质量体系应注意的几个问题新Word下载.doc》由会员分享，可在线阅读，更多相关《软件企业建立质量体系应注意的几个问题新Word下载.doc（47页珍藏版）》请在冰点文库上搜索。
GB/T18234-2000《信息技术CASE工具的评价与选择指南》
数据：
GB/T1526-1998《信息处理数据流程图、程序流程图、系统流程图、程序网络和系统资源图的文件编制符号及约定》
GB/T13502-1992《信息处理系统计算机系统配置图符合及约定》
GB/T15535-1995《信息处理单命中判定》
GB/T15697-1995《信息处理按记录组处理顺序文卷的程序流程》
质量管理体系：
GB/T19001-2000idtISO9001:
2000《质量管理体系要求》
GB/T19004-2000idtISO9004:
2000《质量管理体系-业绩改进指南》
GB/T19000.3-1997ISO9000-3-97《GB/T19001-ISO9001质量保证标准在计算机软件开发、供应、安装和维护中的应用指南》
行业标准规定：
信息产业部文件信部规［1999］1047号《计算机信息系统集成资质管理办法（试行）》
信息产业部文件信部规[2003]440号文《计算机信息系统集成资质等级评定条件（修订）》
2000年10月16日信息产业部、教育部、科学技术部、国家税务总局《软件企业认定标准及管理办法（试行）》
SJ/T30003-93《电子计算机机房施工及验收规范》
GB2887-89《计算机场地技术条件》
GB9361-88《计算机场地安全要求》
GB/T50314--2000《智能建筑设计标准》
GBJ/T50311-2000《建筑与建筑群综合布线工程系统设计规范》
GBT/T50312-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、典型的软件的生存活动周期阶段划分（LifeCycleMode—生命周期模式）
维护和增强
验收测试
确认测试
系统
验证测试
系统需求
系统联试
软件需求分析
配置项
组装测试
软件概要设计
部件
软件详细设计
单元测试
单元
编码
上图1实际上把软件的生命活动周期过程（LCM）划分成为5个阶段:
1）需求分析（RequirementAnalysis）;
2）设计（Design）;
3）程序编写（Coding）;
4）测试（Testing）;
5）运行和维护（RunandMaintenance）;
每个阶段都有确定的任务，并生成一定规格的文档交送给下一个阶段。
见表1。
表1软件工程各阶段的基本情况
阶段
基本任务
工作结果
占开发期的工作量
参加者
开
发
期
需求分析
理解和表达用户要求，详细定义
系统说明书
20%
用户、高级程序员
设计
建立系统结构
模块说明书
数据说明书
15%
高级程序员
程序编写
编写程序
程序
高、初级程序员
测试
发现错误和排除错误
可运行系统
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.2
7.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.3
6.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.1
7.1,7.2.2,7.3
7.4,7.5,7.6,8.18.2.3,8.2.4,8.5
4.1,5.1,5.3,5.4
5.5.1,5.5.2,5.5.3
5.6,8.4,8.5
7.3.5,7.4.3
8.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.3
从表中反映的上述各个过程与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.213种文挡的生成阶段（表2）：
软件的生命活动周期内各阶段生成的文档（表2）
文档
可行性研究
与计划
代码编写
运行与维护
软件需求说明
数据要求说明
概要设计说明
详细设计说明
测试分析报告
项目开发总结
2，4.2.4记录控制：
计算机业的质量体系运行记录，是用于证实组织有效运行体系，并取得绩效的证据。
其示例有:
——测试结果;
——问题报告;
——更改请求;
——带注释的文档;
——评审记录;
——会议记录;
——审核报告。
所有的记录应清晰,保管方式应便于存取和检索,保管设施应提供适宜的环境,以防止损坏、变质和丢失。
应规定并记录质量记录的保存期。
合同要求时,在商定期内质量记录可提供给顾客或其代表评价时查阅。
记录可以呈任何媒体形式,如硬拷贝或电子媒体。
当记录保存在电子媒体中时,考虑保存时间和记录的可访问性时应考虑到电子图像的退化速率,以及为访问记录所需的设备和软件的可用性。
3，5.4.1“质量目标”：
软件业的质量目标的建立和确定应依据GB/T19000.3-1997ISO9000-3-97《GB/T19001-ISO9001质量保证标准在计算机软件开发、供应、安装和维护中的应用指南》，GB/T12504-1990《计算机软件质量保证计划规范》和GB/T16260—1996idtISO/IEC9126:
1991《信息技术软件产品评价质量特性及其使用指南》的规定，建立和确定企业的“质量目标”。
按照GB/T19001-2000标准要求，所建立的质量目标应是“可测量的”，并能分解到企业的各个管理层次，与企业的质量方针保持一致。
此处“可测量的”意思是指“可度量”和“可感知”两个方面。
因此，参照GB/T16260-1996idtISO/IEC9126:
1991《信息技术软件产品评价质量特性及其使用指南》的规定和TL9000R3.0《质量管理体系要求手册》和《质量管理体系测量手册》中有关软件产品的测量指标要求，“可度量”的概念讲，应包含：
（1）软件的系统中断（SO）：
指对计算机系统集
升级会员 