软件质量控制方法

软件质量控制方法（精选10篇）

软件质量控制方法 篇1

摘要：应用软件质量的形成在应用软件开发的过程中,保证软件的质量就要在软件开发的过程中对软件进行质量控制,本文通过分析应用软件的通用过程模型,形成了应用软件的质量过程控制模型,具体分析了质量过程控制模型中的控制手段,提供了比较适合一般应用软件的控制指标。

关键词：软件过程,软件质量,模型,方法

1 引言

中国经济和社会发展处在重要的战略机遇期。中国政府提出要以信息化带动工业化,以工业化促进信息化,走以科技为先导的新型工业化发展道路。信息产业成为国民经济的基础产业、支柱产业和先导产业。信息化是一项复杂的工程,而应用软件处于整个信息化的顶层,涵盖整个信息系统工程的应用部分。信息化建设中无论是网络建设还是服务器配置,最终的目标还是为了应用软件的应用,应用软件是整个信息系统工程的最终表现形式,并最终实现用户的业务目标。所以,应用软件实施的成功与否,直接关系到信息化的成功,应用软件才是信息化建设中的重中之重。

应用软件的建设一般是周期长、知识密集、高风险的系统工程,其复杂性既由于技术的复杂,又由于协调的复杂,而且当两者结合起来以后,其复杂性就尤其突出。应用软件的实施重点就是保障软件的质量,而应用软件的质量是最难衡量的,首先,应用软件是知识密集型的脑力劳动,由于每个人的能力不同,导致了软件的质量无法简单的衡量;其次,软件最终的形式是一些程序代码,由于业务流程繁杂,而且容易受运行环境的影响,所以不能通过一般简单的感观评估的方法进行质量保证;最后,应用软件开发是一个系统的过程,最注重过程的质量保证,如果问题在最后时刻发现,往往项目已经与事无补。所以,如何有效的保障应用软件的质量一直是一项复杂的课题。

2 应用软件的过程质量分析

由于应用软件的复杂性,分析软件的质量,首先要分析软件开发的过程,建立软件过程的质量模型,然后才能对应用软件的过程质量进行控制分析。由于目前的软件的开发模式很多,如线性顺序模型(The Linear Sequential Model )、原型实现型模型(The Prototyping Model)、快速开发模型(Rapid Application Development Model)、渐近式软件开发模型(Evolutionary Software Process Model)等模型,各种开发模式的不同,导致应用软件的开发过程也存在差异。所以,如果分模型进行软件的过程分析,是非常复杂的。幸好ISO(国际标准化组织)为我们定义了通用的软件工程生命周期,来适应不同的开发模型。在软件工程生命周期中,开发过程如图1所示。由于他是一个通用模型,我们可以在这个模型的基础上分析应用软件的过程质量。

从图中我们可以分析软件过程把软件质量的形成过程分成如下几个阶段:

(1)软件需求分析阶段。这是软件开发过程中最重要的内容,他是应用软件质量的开始,也是应用软件质量的基础,

(2)软件设计阶段。本阶段包括软件的结构设计和软件的详细设计。他决定了软件开发的程序框架,同时,他也要与软件的需求相对应,所以也是应用软件质量控制的重点。

(3)软件编码和测试。本阶段包括应用软件的编码过程和软件的单元测试过程。他最直接的影响软件的质量,同时,单元测试也是后面其他各种测试的基础。

(4)软件集成和软件合格性测试。本阶段主要进行软件模块的组装,同时,对软件各模块之间的功能进行测试。所以,本阶段决定了各模块之间是否能协同工作的质量。

(5)系统集成和系统合格性测试。本阶段主要是对软件在真实环境下的运行情况进行测试,以保障软件质量,以适应他运行的环境。

(6)软件验收。本阶段主要是对软件进行验收,从整体的角度对软件进行分析和评价。

从模型中,还有系统需求分析和系统结构设计阶段,这个过程由于是涉及到系统级的需求分析和系统级的结构设计,超出了本文研究的应用软件的范围,所以本文暂时不对他进行分析。但系统需求分析和系统结构设计对整个系统的质量有很大的影响,尤其是大型系统内各系统的接口、数据资源共享问题,所以,系统需求分析和系统结构设计对系统质量的形成是非常重要的。

针对应用软件质量的形成过程,我们对软件质量的控制主要体现在过程中的质量控制,同时,我们在建立应用软件质量的过程控制模型时还需要考虑质量控制的成本,必须在最关键的地方建立质量控制。所以,我们建立应用软件质量的过程控制模型如图2所示。

控制模型分析如下:

(1)软件需求分析阶段:主要的质量控制手段包括需求过程质量保证,需求评审。

(2)软件设计阶段:主要的质量控制手段包括设计评审。

(3)软件编码和测试阶段:主要的质量控制手段为软件的单元测试。

(4)软件集成和软件合格性测试阶段。主要的质量控制手段为软件合格性测试。

(5)系统集成和系统合格性测试阶段:主要的质量控制手段为系统合格性测试。

(6)软件验收支持阶段:主要的质量控制手段为软件验收测试。

3 应用软件质量的过程控制指标分析

形成应用软件质量的过程控制模型后,需要具体的对过程控制指标进行分析,具体指标分析如下:

3.1 应用软件需求分析阶段

本阶段是软件开发过程的起始阶段,是后面各个阶段的基础,所以本阶段的质量要求非常高。具体手段包括需求过程质量保证和需求评审。

需求过程质量保证主要控制点包括:总体计划是否合理,是否有配置管理计划、需求调研工作计划。调研过程是否按计划进行,调研方法是否合理,是否有调研问题跟踪记录、需求变更流程是否完备,需求是否用户确认等。

需求评审主要控制点包括:需求文档是否描述了详细的功能与能力规格说明,包括性能、物理特性和软件项执行的环境条件。是否描述了验收需求、安全需求、数据需求等内容。是否描述了用户文档、用户操作与执行需求、用户维护需求、易用性需求等内容。另外,需要评审需求文档是否与合同有可追溯性和一致性,与业务目标和系统建设目标是否一致等。

3.2 应用软件设计阶段

设计阶段是关系到后面开发质量的重要环节,同时,他也起到承上启下的作用,即把用户的需求与真实的程序语言关联起来。设计阶段重要的质量控制手段就是应用软件的设计评审。主要分析的内容包括与软件需求的可追溯性和一致性,所采用的设计方法和标准的适宜性;后期开发、运作与维护的可行性等。

设计阶段在进行设计评审的过程中,除了运用和需求评审一样的审核手段外,还有一些技术手段来进一步确定软件设计,主要如表1:

3.3 软件编码和测试阶段

本阶段的质量控制手段主要是软件单元测试,软件单元测试的对象是可独立编译或汇编的程序模块。单元测试在开发阶段后期同步进行。软件单元测试的目的是检查每个软件单元能否正确地实现设计说明中的功能、性能、接口和其他设计约束等要求,发现单元内可能存在的各种差错。

软件单元测试一般应符合以下技术要求:对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试;每个软件特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖;测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值;在对软件单元进行动态测试之前,一般应对软件单元的源代码进行静态测试;语句覆盖率达到100%;分支覆盖率要达到100%;对输出数据及其格式进行测试。

3.4 软件集成和软件合格性测试阶段

本阶段的质量控制手段主要是软件合格性测试或者软件集成测试,测试的目的是检验软件单元之间、软件单元和已集成的软件系统之间的接口关系,并验证已集成软件系统是否符合设计要求。

软件合格性测试一般应符合以下技术要求:软件要求的每个特性应被至少一个正常的测试用例和一个被认可的异常测试用例覆盖;测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值;应逐项测试软件设计文档规定的软件的功能、性能等特性;应测试软件之间、软件和硬件之间的所有接口;应测试软件单元之间的所有调用,达到100%的测试覆盖率;应测试软件的输出数据及其格式;应按设计文档要求,对软件的功能、性能进行强度测试。

3.5 系统集成和系统合格性测试。

本阶段主要进行系统集成,所以,本阶段的软件基本成熟,需要通过系统合格性测试(系统测试)对软件的质量进行全面的检验。

系统合格性测试一般应符合以下技术要求:系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖;测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值;应逐项测试系统/子系统设计说明规定的系统的功能、性能等特性;应测试软件配置项之间及软件配置项与硬件之间的接口;应测试系统的输出及其格式;应测试运行条件在边界状态和异常状态下,或在人为设定的状态下系统的功能和性能;应测试系统访问和数据安全性;

本阶段的质量控制由于是对整个系统的检验,所以,一般根据质量特性的要求,对不同的实际问题应外加相应的专门测试。具体的测试内容如表2所示。

3.6 软件验收阶段

本阶段主要目的是让用户确认软件的质量,所以,验收测试也成为交接软件前的最后一道质量保证手段。验收测试的目的是在真实的用户(或称系统)工作环境下检验完整的软件系统是否满足软件开发技术合同(或软件开发任务书)规定的要求。质量手段几乎同系统合格性测试,只不过由用户来实施,侧重点更注重业务的测试。

4 结论

综上所述,通过应用软件质量过程控制的分析,我们可以得到应用软件过程质量控制的手段和指标。通过实施过程控制手段,可以有效的保证软件的质量。当然,本文提供的只是一个软件过程质量的通用模型和通用的指标,对于具体的项目,需要剪裁使用,如小项目可能只选取比较关键的指标和控制手段,对于大项目或对某方面(如安全)要求比较高的软件,可能还需要在此基础上添加一些控制点。总之,只有通过应用软件质量的过程控制,才能保证软件的过程质量,才最终保证软件的整体质量。

参考文献

[1]冯惠,王宝艾,韩红强.GB/T8566《信息技术软件生存周期过程》新版标准说明[J].信息技术与标准化,2006,(08):40-44.

[2]ISO/IEC12207-1995,Information technologe-Software life cycleprocesses[S].

[3]赵晶华,苏秦.软件需求变更过程质量管理及控制初探[J].计算机应用研究,2004(07):31-33.

[4](美)温伯格.质量.软件.管理[M].北京:清华大学出版社,2005.

软件质量控制方法 篇2

随着科技的不断发展，高新科技在金融行业中的应用，让金融知识产品体系成为了金融机构展示自身市场竞争力的重要载体从计算机软件行业的发展来看，软件工程化技术的应用，对软件产品的产品质量的提升起到了积极的促进作用。将软件工程化系统中的核心要素应用于金融产品的质量控制工作之中，可以让金融产品和相关服务的服务质量得到有效提升。

1软件产品工程化

计算机软件产品的生产过程是一种较为严密的智力活动。作为一种特殊的工业产品，计算机软件中也包含着一般工业产品所具备的共性特征[1]。软件产品是对逻辑思维进行描述的过程。结构化的设计方法是软件工程理论中的一项重要内容。在对工程化方法进行应用以后，软件生产单位可以在第一时间发现出软件的设计缺陷。软件产品的工程化在其他的生产领域也具有着一定的参考价值。在软件的开发工作中，技术管理问题涉及到了计划的制定、技术接口的协调和阶段评审等问题。质量保证计划的构建、基于分级管理的软件质量保证体系的构建和配置管理机制的完善是质量管理工作中的主要内容。在高效化的工程组织体系建立以后，软件开发的进度和产品的质量可以得到充分的保障。

2金融产品创新的内涵和动因

2.1金融产品创新的含义

金融产品泛指的是一切可以进行金融交易的对象。除了货币等支付工具以外，存借款、保险产品和证券资产化等衍生类金融工具都可以被看作是金融产品的主要内容。金融产品的创新，涉及到了已有产品的改进、新型金融产品的研发、生产方式的创新和新市场的开拓和经营等多项内容[2]。

2.2金融产品创新的动因

软件质量控制方法 篇3

【关键词】单片机；PWM；LED；节能

1.引言

LED因体积小、功耗低、使用寿命长、高亮度、低热量、环保等诸多优点，广泛应用于照明中。在我们的生活中，为了节省电能，有时并不希望LED以高亮的形式点亮，因此本文提出利用PWM来调控LED的亮度。

2.PWM的基本原理

PWM的基本原理是通过控制固定电压的直流源开关频率，从而改变LED两端的电压，进而达到控制要求的一种调速方法。在脉宽调速系统中，按照一定的频率来接通和断开电源，并根据需改变一个周期内“接通”和“断开”的时间，过改变LED两端平均电压的大小，从而控制LED的亮度。简单来讲，就是在一定频率的方波中，利用PWM调整高电平和低电平的占空比来控制LED的亮度。比如用低电平点亮LED灯，我们可以把一个频率周期分为10个时间等份，如果方波中的高低电平比是9:1，此时LED较暗；如果高低电平的占空比是5:5，此时LED是一个中间亮度；如果高低电平的占空比是1:9，此时LED较亮；如果高低电平的占空比为0:10，此时全为低电平，LED最亮；如果高低电平的占空比为10:0，此时全为高电平，LED全灭。

3.PWM信号的软件实现方法

实现对LED亮度控制的关键在于如何让单片机产生占空比可控的PWM信号。PWM信号的产生有两种方法：一种是软件的方法，另一种是硬件的方法。本文主要介绍一种利用单片机产生PWM信号的软件实现方法。软件的基本思想是：利用单片机内部定时器/计数器T0产生一定频率的低电平信号点亮LED，利用定时器/计数器T1产生一定频率的高电平信号关闭LED，同时外接两个独立按键配合T1来控制产生高电平的频率，从而达到高低电平可调的信号，实现从单片机的的P0口输出不同占空比的脉冲波形，达到调节LED亮度。软件实现方法如下：

#include

#define uchar unsigned char

#define uint unsigned int

sbit Add_key = P3^2;

sbit Sub_key = P3^3;

uchar pwm = 0x7f;

uchar count = 0;

void Delay(uint t)

{

uint i,j;

for(i=0;i

for(j=0;j<120;j++);

}

void Init(void)

{

TMOD = 0x21;

TH0 = (65536-1000)/256;

TL0 = (65536-1000)%256;

TH1 = pwm;

TL1 = pwm;

EA = 1;

ET0 = 1;

ET1 = 1;

TR0 = 1;

}

void main(void)

{

Init();

while(1)

{

do

{

if(pwm!=0xff)

{

pwm++;

Delay(10);

}

}

while(Add_key==0);

do

{

if(pwm!=0x00)

{

pwm--; Delay(10);

}

}

while(Sub_key==0);

}

}

void TimeT0() interrupt 1

{

TH0 = (65536-1000)/256;

TL0 = (65536-1000)%256;

P0 = 0x00;

TR1 = 1;

}

void TimeT1() interrupt 3 using 0

{

TR1 = 0;

TH0 =PWM;

P0 = 0xff;

}

根据上述程序，搭建实验电路进行调整，通过示波器观测到单片机的P0输山信号如图1、图2所示。表明本程序完全可行，能够有效获得所需的PWM信号。

4.结论

通过单片机来调节LED的亮度，相对于其他用硬件或者硬软结合的方法实现对LED亮度的调节，采用单片机产生PWM纯软件的方法来实现对LED亮度调节，具有更大的灵活性和更低的成本，能够充分发挥单片机的效能，对于简易亮度控制系统的实现提供了一种有效的途径。

参考文献

[1]李秀忠.单片机应用技术[M].华南理工大学出版社,2009.

[2]彭伟.单片机C语言程序设计实训100例[M].电子工业出版社,2009.

[3]李光飞.单片机C程序设计实例指导[M].北京航空航天大学出版社,2005.

作者简介：鲁刚强，成都农业科技职业学院电子信息分院教师，主要从事应用电子技术方面的研究。

软件质量控制方法 篇4

0前言

计算机软件在运行过程中难免会出现一些故障, 有一些软件故障是由于软件本身质量问题而导致的, 提高软件开发质量也是减少软件故障的一个较为有效的方法。对于软件系统建立一个比较通用的质量评价模型已成为一个研究热点, 基于此提出面向领域的一种软件质量评价模型构建方法, 对于提高软件质量, 评价软件系统具有积极的作用。

1 软件故障分析

1.1 产生软件故障的原因

计算机软件系统运行所需环境各不相同, 如果用户的计算机设备及软件配置不能达到软件需要, 就容易发生功能性故障。结合软件维护实际情况分析, 软件故障产生原因主要有下列几个:一是内核文件丢失或系统配置出现错误;二是程序受计算机病毒破坏而不能正常运行;三是设置CMOS参数不正确;四是内存管理中存在一些冲突;五是计算机软硬件不兼容;六是由用户操作不当造成的。

1.2 软件故障分析方法

综合分析产生上述软件故障的原因, 可将软件运行环境分为三个层次接口, 与此相对应也可将故障分为用户接口、硬件接口、软件接口三类接口故障。当计算机发生故障时可采取观察法、对比法、更换法等判断故障是由于硬件还是软件引起的, 并确定故障源。排除软件故障过程中也要考虑软件运行环境是否满足要求, 依次分析用户接口、硬件接口、软件接口大都可确定故障原因并进行解决。对软件故障重复性进行验证, 注意软件故障发生的操作顺序及状态。软件使用过程中要定期进行备份, 避免软件发生故障时损失重要数据。

2 软件质量评价模型

2.1 领域质量评价模型

领域软件质量评价模型是由抽取标准模型中符合目标领域的特性项与抽象目标领域系统的领域特征项相结合而形成的。该模型基于标准模型进行剪裁与扩展, 仍具有属性、特性、子特性三层结构。在对目标领域系统进行评价过程中, 要将领域通用模型实例化才能转化为目标领域质量评价模型。

由于领域软件需求一般分为可选和必备两种, 因此在该模型中待评价的每层元素也同样分为可选和必备。领域质量评价通用模型的所有项都是可选, 对于目标领域质量评价模型具体到实例化时, 要对各项关系性质进行确定。该模型建模步骤如下:一是将标准模型中的特性项抽取出来, 结合目标领域特点, 对标准模型中符合目标领域软件的度量、特性及子特性项抽取出来;二是根据目标领域需求构建框架, 输入软件及领域知识, 软件目标领域实例及有关文档由领域专家进行分析, 以确定必备与可选需求, 可与上步骤同时进行将领域需求框架进行输出;三是特征抽象, 基于领域专家分析领域需求框架, 辅助评测专家对领域特征进行抽象;四是特征映射, 抽取特性、子特性、属性项及领域特征要向通用模型进行映射, 至此具有领域功能性、可靠性、易用性、领域效率、领域维护性、领域可移植性的目标领域软件质量评价模型构建完成。

2.2 质量评价

领域质量评价模型要进行有效性验证, 结合软件根据评价需求、规定评价、设计评价、执行评价等步骤对待评软件系统实施评价。评价需求确立时, 要结合评价参照的质量评价模型进行确定。采用专家评定与三角模糊数层次分析法对各特征值进行赋权, 对同层次对象要由多个领域专家进行两两之间的比较, 采用三角模糊数形式对相对重要程度进行表示, 多个比较矩阵可取其平均值作为被比较对象建立模糊比较矩阵。模糊数对应的截集矩阵要通过隶属函数进行求解, 其中各元素可作为模糊数的置信水平确定的一个置信区间, 并对乐观水平进行设定后转化为判断矩阵。然后对判断矩阵最大特征值及对应特征向量进行求解, 以判断验证矩阵是否一致。如果存在不一致情况, 要对判断矩阵进行调整, 否则可将特性向量向权重向量进行归一。

3 结语

综上, 本文提出的面向领域质量评价的一个通用模型, 提出的评价方法需要在实际应用中不断进行完善。该模型可用于对软件质量评价的一个有效手段, 基于该模型对常用软件系统进行客观评价, 评价结果符合应用实际, 说明此模型可作为软件系统的评价基准, 使用面向领域的质量模型对目标领域软件质量进行评价具有可行性, 可以使评价公正客观且准确, 对于提高软件开发质量, 促进信息产业发展都具有十分重要的意义。

参考文献

[1]雷祥, 张少华, 任凌云, 王彦理.D-P算法的改进及其在飞行轨迹回放中的应用[J].软件, 2012, 33 (9) :149-150

[2]吴小帆.CIN-SCF系统可视化信令跟踪工具的设计与实现[J].软件, 2013, 34 (8) :78-81

[3]Kwong C K, Bai H.A Fuzzy AHP approach to the determination of importance weights of customer requirements in quality function deployment[J], Journal of intelligent manufacturing, 2010.5

焊接质量控制方法 篇5

在汽车生产的四大工艺冲压、焊接、涂装和总装中，焊接工艺起着承上启下的作用，焊接质量的好坏，不但对车身的安全性有密切的关系，同时对车身内外饰件的装配和车身外观质量等方面都起着至关重要的作用。据统计，一辆白车身焊点数量将达到5300～5600个，因此做好电阻点焊焊接强度的控制，对保证焊接质量起着非常重要的作用。

为保证白车身的焊接质量，必须要建立起相应的质量保证体系。如前期焊接质量策划、焊接过程监控和焊后检验等手段。前期焊接质量策划主要包括焊接设备的选型、焊接工艺方法的评定和检验项目的确定。焊接过程监控则主要是利用计算技术对电阻点焊过程的焊接参数进行实时监控。监控信息必须与焊接质量有密切的关系，呈一定的函数关系并有期望的准确度；信噪比要足够高，信号再现性好，检测手段易实现等特点[1]。

目前常用的监控方式有：①温度监控；②超声波信号监控；③声发射监控；④点阻焊接参数监控；⑤焊点热膨胀监控[2]。其中对电阻点焊焊接参数监控方式有恒流控制法、恒压控制法和恒功率控制法等。但由于过程监控需要使用大量在线计算，除对计算机硬件要求较高外，日常维护花费也较大。

目前，生产中应用普遍还是对焊接工艺装备的日常工艺参数监控的方法。焊后检验主要包括无损检测、破坏性检测和非破坏性检测等。下面简单说一下日常焊接工艺参数监控方法和焊后检验。

焊接工艺参数的日常监控

在前期焊接质量策划中，控制计划规定对产品性能和产品质量有影响的各项焊接工艺参数有：焊接电流、焊接时间和电极压力等。

首先由焊接车间每月末编制下个月的测量计划，编制完成后交工艺部和品质部进行审核，审核无异议后，由品质部安排人员实施检测计划，在检测过程中若发现异常状况，焊接车间应进行产品追溯排查，同时通知工艺人员进行参数确认工作，调整输入参数后，再进行产品试焊，确认调试后焊接质量，直到符合标准要求为止，并将修改后焊接参数进行保存。其中对关键工位的检测频次做到1次/周，普通焊接工位为1次/2周。焊后检验

焊接后检验主要包括焊点强度质量检验和焊点外观质量保证。

3.1 焊点强度质量检测。焊后检验分为破坏性检验和非破坏性检验。破坏性检验是对需要检测的焊点进行破坏检测的方式。非破坏性检测主要是由生产线各工位对可錾焊点进行质量检验的方法。通常非破坏性检测可以发现简单的焊接缺陷，如虚焊、弱焊等。非破坏性检测一般安排5次/班，首次规定在开班正式生产前进行，并将检测的试片保存。在生产过程中每间隔一定时间，再安排余下的检测试验。如果发现焊接质量不合格的焊点应立即采取措施进行控制，并对前序的产品进行追溯。

破坏性检测是对整个车身焊点进行逐一检查，比较全面，可以发现所有不合格的焊点。但是，经破坏性检测后的车身只能做报废处理，且抽样频率较低，不利于问题的及时发现和处理。

目前对焊点强度的检测正向无损检测方式发展，无损检测就是在不损害或不影响被检测对象使用性能的前提下，通过射线、超声波、红外线和电磁等物理方法对焊接质量进行检测的方法。其原理主要是通过利用物质的声、光、电和磁场效应，对被检测对象中是否存在缺陷进行判断，同时还能对缺陷的大小、位置等信息进行采集。由于无损检测具有非破坏性，操作方便、快捷等优点，已被广泛应用到生产实际中。

3.2 焊点外观质量保证。对焊点进行的外观检查。焊点外观缺陷主要有：焊点扭曲、焊点压痕过深、烧穿、未焊透和毛刺飞溅等。根据焊点在车身所处的区域确定焊点外观质量等级。整车焊点外观等级分为3级，每级允许存在的焊点外观缺陷的数量和严重程度有所差别。

根据对焊点强度检测和外观质量的检查，可以计算出被检车身焊点的质量水平值（NQST）。以此可以衡量和控制车身焊点强度质量。NQST（焊点质量水平）值=缺陷焊点数/总焊点数x100%[3]。NQST完成后，应及时组织相关部门召开NQST分析会，将焊点的缺陷问题进行分类并划分责任部门，各责任部门按照PDCA（plan计划，do执行，check检查，action行动，又叫质量环）模式对问题进行整改，并进行验证。通过对产品质量的改进和整改措施的执行，会不断降低NQST的值，提升车身焊点综合质量。结束语

软件研制过程中的质量管理与控制 篇6

关键词：质量管理,软件测试,软件能力成熟度模型

0引言

国际化标准组织ISO在ISOPIEC9126中将软件质量定义为:“反映软件产品满足规定需求和潜在需求能力的特征和特征的总和。”软件研制过程中质量管理保证和质量控制过程域是重中之重。软件质量管理包括:质量计划编制、质量保证和质量控制3个过程域。质量计划是质量管理的第一过程域,它主要结合各个公司的质量方针、产品描述以及质量标准和规则,通过收益、成本分析和流程设计等工具制定实施方略,其内容全面反映用户的要求,为质量小组成员有效工作提供了指南,为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据,为确保项目质量得到保障提供坚实的基础。质量保证则是贯穿整个项目全生命周期的有计划和有系统的活动,经常性地 针对整个 项目质量 计划的执行情况进行评估、检查与 改进等工 作,向管理者、顾客或其他方提供信任,确保项目 质量与计 划保持一致。质 量控制是 对阶段性 的成果进 行检测、验证,为质量保证提供参考依据,它是1个PDCA循环过程。PDCA循环由美国质量管理专家戴明博士提出,是全面质 量管理所 应遵循的 科学程序。

1软件开发研制过程

软件质量管理贯穿于整个软件的研制过程。软件的开发研制过程一般分为:顶层设计、需求分析、软件设计、实现与测试、软件评测、用户试验试用、设计定型等几个阶 段。软件的开 发研制过 程如图1所示。

在软件研发实践中,软件质量控制可以通过各阶段的流程 管理 (缺陷处理、文 档控制、发布 过程等),严格执行软件过程管理规范,从而保证软件产品质量。例如,软件研制和管理的全过程需要软件配置管理、质量保证、各级测试、软件培训、系统验收及服务维护来支撑。通过立项管理、项目规划、项目监控、需求管理、风险管理及结项管理等阶段对软件的质量进行严格的监督和管理,确保软件研制中的全过程质量可控、可靠。

2软件研制过程中的质量管理

2.1项目进度质量保证

项目进度是 项目进行 顺利与否 的最直观 表现。显然在项目开 始之前,项目开发 计划是必 需的。如果项目开发 计划的制 定是完全 合理的,那项目进度也就真正表达了项目与 最终的交 付使用之间的距离,然而要制 定完全合 理的项目 开发计划几乎不 太可能。可见 要保证项 目进度,首先要保证项目开发计划 尽可能合 理。项目计划 的合理程度与项目计划制定者从事 类似规模 和类似业 务的项目经验有直 接关系,通过经验 往往能够 预见潜在阻碍,这样要求 项目计划 制定者需 要集众人之力来 完善计划。项 目计划制 定初期,由质量保证小组组 织召开项 目计划评 审会,邀请公司 技术专家、用户以及 项目组小 组成员一 起讨论项 目计划的可行性。会 议通常采 用头脑风 暴法,各抒己见,会后由指定的记录员形成质 量记录,发送给相关人员,对其计划中不合理的地 方进行修 改完善,并由质量保证人 员对其结 果跟踪,以确保项 目计划完整性、可行性,完善后的计划 交由配置 管理人员进行版本控制。然而在计划实施过程中,计划不是“固定化”。常言 道,“计划赶不 上变化”,但“要跟上变化”,项目计划 以里程碑 为界限,将整个开发周 期划分为 若干阶段。 根据里程 碑的完成 情况,适当调整每一 个较小阶 段的任务 量和完成 的任务时间,这种方式 非常有利 于整个项 目计划的动态调 整,也利于项 目质量保 证的实施。实 际运作中,当质量保证小组发现计划 实施的差 异后,报告项目经理,由项目经 理负责组 织对计划 进行周期性维护,对于已经 变动的计 划由质量 保证小组协助配置管理小组完成版本控制。

2.2项目开发的各阶段质量保证

(1)需求分析阶段

需求分析是系 统建设的 开端,也是项目 建设的基础[2]。从系统分 析经验来 看,这个过程 往往是循序渐进的 过程,一次性对 系统形成 完整的认识是困难的。只有 不断地和 客户领域 专家进行 交流确认,方能逐步 明了用户 的需求。从系 统开发过程得知,系统分析时犯下的 错误,会在接下 来的阶段被成倍 地放大。越是 在开发的 后期,纠正分析时犯下的 错误所花 费的代价 越是昂贵,也越发影响系统的工期和 系统的质 量。解决系统 分析错误的方法,通常采用邀请用户 参与进行 需求评定,然后对其用户的意见由质量保 证成员跟 踪检测是否纳入需 求规格说 明书,同时与用 户签字确 认形成需求基线,交由配置 管理员放 入配置管 理库。虽然尽早地邀 请用户参 与,仍然避免 不了项目 进行中用户需求的变更请 求。对于开发 过程存在 的需求变动,要求用户 填写变更 申请单发 送给项目配置管理 员,再通过配 置管理员 转交质量 保证小组,负责组织专家 小组和项 目组成员 一起讨论 实施变更的可行性及实施 后所带来 的影响。小的 变更则直接录入变 更记录原 因分析项 和风险项 栏;大的变更则需要 形成正式 变更报告,无论哪种 变更都需要对相应 的文档实 施同步变 更 (包括需求规格 说明书、详细 设计文、安装 手册、操作手 册等)。但是对于无法实 现或是变 更会带来 巨大影响而将导致 进度的延 期时,将变更报 告提交给 用户或邀请用户进 行协调会 议,讨论变更 取舍问题或是项 目进度变 更问题。决定 变更之后,由项目经理组织实施变更,测试人员 检测变更 结果,而质量保证小组成员监督变更实 施过程并 协助配置 管理员对变更 后的成果 进行版本 控制。变更 实施后,上线前还需要 指定人员 协助用户 一同测试 并由用户签字同意后方可上线。

(2)系统设计阶段

优良的体系结构应当 具备可扩 展性和可 配置性,而好的体系结构则需要好 的设计方 法,自然设计选型成为系统设 计首要工 作。需要针对 项目结构、项目特征和用户需求 来分析,同时也要 考虑参与项目小组成员的 素质。面向对 象设计方 法采用面向过程的方式(除用户指定开发设计方式 外)可以减少项目承担的技术风险。除设计选型,还有1个容易被忽视的问题就 是公共类 开发。公共类 开发可以减少工作中的重复工作、降 低开发成 本,这要求在设计阶段 通过对用 户需求的 仔细研究,尽可能地识别出公 共类并进 行定义,指定专人 负责设计,通知其他设计人员,以减少重 复工作。对于项目组提 供的设计 文档,由质量保 证小组组 织技术专家、项目组设计人员、开发人 员和测试 人员对其设计文档 评审,检测设计 文档对其 下一阶段 工作的可行性,及时发现设计中可 能存在的 错误,降低项目开发风险,同时确保 设计文档 能为开发 人员、测试人员提 供切实的 指导。对于可 复用的设计进行提 取作为公 共库设计 和开发,提供项目 组或整个公司重用,最后交由 配置管理 员进行设 计文档的版本控制。

3软件研制过程中的质量控制

3.1健全质量管理体系

ISO9001规定了企业 质量管理 体系的基 本要求,它适用于所有行业或经济领域,不论其提供何种类别的产品。ISO9001本身并不规定产品质量的要求,为促进质量目标的实现,ISO9001标准明确规定了以下8项质量管理原则:

(1)以顾客为关注中心;

(2)高层管理者的推动;

(3)全员参与;

(4)采用过程方法;

(5)管理的系统方法;

(6)持续改进;

(7)基于事实的决策;

(8)供方互利的关系。

任何“得到输入并将其转化为输出”的序列活动均可视为过程。为了使组织有效运行,必须识别和管理许多内部相互关联的过程。通常,一个过程的输出将直接形成下一过程的输入。系统识别和管理组织内所使用的过程,特别是这些过程之间的相互作用,称为“过程方法”。

3.2软件能力成熟度模型集成

软件能力成熟度模型集成(Capabilitymaturitymodelintegration,CMMI)是在美国国防部的资助下,由卡内基梅隆大学软件工程研究所(SEI)建立,用于评价软件开发组织 软件过程 能力成熟 度的模型。后来此模型被用于软件开发组织内部的软件过程改进。

需要CMMI原因如下:

(1)软件过程评估(SPA),即指出该企业所面对与软件过程有关、最急需解决的问题,以便改进。

(2)软件过程改进(SPI),即帮助企业对其软件过程向更好的方向改变。

(3)软件能力评价(SCE),即鉴别软件承包者的能力资格或检查/监督正用于软件制作的软件过程的状况。

CMMI阶梯式表示法,即组织成熟度方法如图2所示。

3.3加强质量过程域的监督

3.3.1加强测试工作,并形成制度

软件开发过程包含了软件需求分析、体系结构设计、代码开发和变更、软件集成、各级测试、产品交付等所有活动和任务的全过程[3]。测试就是对软件产品的检验。测试是保证软件质量的重要手段,软件测试可以发现软件中大多数隐蔽的错误,测试越充分,软件中的隐患就有可能暴露得越彻底[4]。软件测试的目的是根据用户需求检查系统是否符合项目合同与任务书规定的要求。项目测试分集成测试和系统测试,主要进行功能测试、健壮性测试、性能效率测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等活动。有计划地强化测试环节,让用户自始至终地参与测试工作。测试活动要尽可能 覆盖整改项目过程,从最初的需求到部署阶段,都应该制定详细的计划 并编制相 应的文档,如测试计划、测试用例文 档、测试报告等。在测试活动过程中,应该遵守 一条基本 原则———按照用户 需求进行测试。既 不能为求 速度而缩短测试规模,也不能忽视用户 需求而提 高测试要求。总之,一切测试应该符 合用户需 求。软件整个测 试过程如 图3所示。

3.3.2使用软件配置管理对软件版本进行变更和控制

软件配置管理是软件工程的一个基础活动,它始终贯穿软件的整个生命周期。在项目管理理念中变化是永恒的,不变是短暂的,特别是在软件开发项目中需求的变更是最常见的。变更不只局限需求方面,但需求的变更可能意味着项目的范围发生了变化,那么设计、开发和测试工作都会受到影响。在一些管理不规范的项目中,经常会出现一些被修复的缺陷又再次发生,一些新开发的功能又不见了,之前测试通过的项目又出现问题等情况。这些情况有可能是因为开发人员把代码互相覆盖造成的,也就是说软件产品版本出现混乱。因此在软件开发过程中引入软件配置管理是必要的,其目的就是为了对软件产品的可回溯性和完整性提供保障,简单来讲就是要将软件开发过程中的各种工作成果管理并控制起来。变更配置项状态图如图4所示,变更控制流程图如图5所示。

3.3.3软件质量保证(Softwarequalityassure,SQA)是质量控制的基础

SQA的目的是为管理者提供有关软件过程和产品适当的可视 性[5],是为了确 保软件开 发的流程按照事先 定义的规 范开展,从而使软 件质量得到提高。以软件质 量控制的 结果作为 工作的重 要输入,SQA保证在质量 体系中实 施全部的 计划和活动,以保证质 量得到提 高。它是以非 技术为手段,从源头防止缺 陷的产生,并贯穿项 的始末,属于管理职能。制定SQA计划,确保正确执行,明确审计内容和重点 进行审计,报告审计 结果并跟 进直到解决。软 件质量保 证角色和 职责的分 配如图6所示。

4结束语

软件质量控制方法 篇7

国内外针对软件质量评估提出了很多质量度量模型。 1968年由Rubey和Hurtwick就软件的一些特性提出了度量方法, 但尚未建立质量度量模型, 所提出的度量方法也不完整。1976年, Boehm等人提出了定量的评价软件质量的概念, 给出了60个质量度量公式, 首次提出了软件质量的3层模型。1978年, Waters和McCall提出了从软件质量要素、准则到度量的3层次式的软件质量度量模型。McCall认为, 软件的质量有11个要素构成, 即正确性、可靠性、效率、完整性、可使用性、可维护性、可测试性、灵活性、可移植性、重复使用性和连接性。 ISO 于1985年提出建议, 软件质量度量模型由3层组成:高层软件质量需求评价准则、中层软件质量评价设计评价准则和底层软件质量度量评价准则。ISO3层次模型来自McCall等人的模型, 高层、中层、底层分别对应与McCall模型中的特性、质量准则和度量。

上海软件中心根据ISO/TC97/SC7的建议, 同时参照McCall模型和Boeing模型, 并结合我国实际情况综合构成了SSC (Shanghai Software Center) 软件质量度量模型及度量方法, 从而形成了SSC软件质量评价体系。

2代码审查与评价

2.1检查表设计

缺陷检查表是根据软件质量度量特征归类编写的一些通用的、良好编程规范或者编程注意事项, 本文称之为评价原则, 严格遵循这些原则进行编程能够保证代码质量的各种特性的提高。缺陷检查表设计结构如图1所示。

其中a1, a2, a3, …, an为各项质量特性的权重。

每类质量特征包括多条评价原则, 每条评价原则从程序代码的角度来阐述了程序应该遵循的编写规范, 检查表设计时候应该注意尽量全面概括某一个质量特性的各项评价原则, 保证同一质量特性中各条评价原则彼此独立、互不干扰或者重叠。

2.2度量权重设计

对于不同的软件产品根据其性质的不同, 质量衡量的标准也不同。例如国防武器系统和商用电子制表软件对其质量的要求是不同的, 国防武器系统可能对安全性、易维护性要求更高;而商用电子指标软件可能对其可靠行、易用性、易移植性要求更高。因此, 在评价一种软件产品之前首先要对每种度量特征规定相应的权值。

这里的权值只是一个相对的数字, 例如:如果对可移植性要求只是一般, 则可将可维护性权值设定为3, 如果对可靠性要求较高, 可将其设定为5, 依次类推为每项质量特性根据具体情况设定相应的权值, 最后得到权重矩阵A=[a1, a2, a3, a4, a5, a6]。因此对于国防武器系统, 电子商务系统可能的度量权重设计模式分别如表1、表2所示。

3缺陷统计分析

3.1抽样审查

对待评估系统的全部代码进行抽样, 例如从系统全部代码中随机抽取n份代码, 每份代码包含m行代码 (多余m行的可以从中随机截取m行代码) , 这里n代码相当于n次抽样, 显然, 每组抽样缺陷数据都来自于同一样本空间。

对抽取的每份代码参照代码检查表进行逐行评审, 找出每份代码中的缺陷, 并将其按照软件度量特征进行归类记录, 这样就可以得到n份抽样数据, 每份抽样数据表明在固定的行代码中发现的各类缺陷数总数, 对于第i份代码而言, 假设对每类缺陷的累计计数分别为ωi= (ωi1, ωi2, ωi3, …, ωi6) , 其中ωik, 1≤k≤6是第i份代码第k类质量特性的最终缺陷总数, 从而这份代码的综合缺陷贡献分值为undefined, 全部这些通过评审得到的数据组成了一个样本集, 记作R= (r1, r2, r3…rn) 。

通过将归类于某项度量特征的缺陷数与该度量特征类型的权重进行加权, αjωij从而达到区分软件关键质量特征的目的。

3.2求解缺陷分部函数

将每份代码的最终评价得分R作为随机变量, 假设此随机变量R满足正态分布N (μ, σ) , 利用中心距最大熵法可以求解该分布的参数σμ, 分布函数为undefined。在这里t为每份抽样代码中发现的缺陷数所贡献的分值, F (x) 的实际意义代表全部抽样中每份样本代码中包含的缺陷所贡献的分值小于x的概率。

4质量等级度量

引入评价集Vk= (vk1, vk2, vk3, …vki) , 其中, vki由具体的软件质量测评部门根据软件的特性和实际经验给出, k为每行代码规定的缺陷贡献分值的上限, vki (i=1, 2, 3, …, n) 对应着一个综合质量等级标准, vk1

若F (k) >vki, 则说明该抽样代码的质量标准达到了第i个级别, 从而可以评定被检测系统代码质量等级最低为i级。

至此对软件系统的综合质量水平已给出了一个量化水平标准, 通过建立的缺陷分部函数可以很容易地得出被评测软件综合质量水平。

5结束语

本文论述方法的优点在于从软件系统内部进行抽样分析判别, 从而从实质上把握了软件的缺陷, 具体有以下几个方面:①能够从除测试之外的另一个角度评估系统的质量, 弥补了仅仅通过系统测试来评估软件系统质量的不足之处;②可操作性强, 评估结果在一定程度上量化了软件的综合质量, 弥补了仅仅通过千行代码缺陷数的不足之处, 为开发高质量的软件产品提供了必要的保证。

该方法的不足之处在于:①基于代码缺陷分析的软件质量评估方法对工作的人员要求较高, 要对程序设计和业务领域有比较深入的了解;② 本文对代码缺陷分布遵循的模型假定为正态分布, 这满足一般的经验, 一定程度上能够满足应用, 但是还缺乏理论验证;③ 通过本文提出的方法最终得到的是可靠性特征、效率特征、可维护性特征和可移植性特征等几个软件质量方面的综合评价, 而没有对某一个方面给出具体的量化参数。

摘要：评价一套软件系统的质量, 一方面要对其所表现出来的外部特征进行研究, 另一方面还应对其内部结构进行分析。因为构成软件系统的程序代码质量如何直接决定了整个软件系统的质量水平, 所以程序代码中的缺陷分布特征也直接反映了软件系统的质量特征。介绍了如何通过抽样审查程序代码的方法建立软件缺陷分布函数, 从而达到由软件缺陷分布来对软件质量进行综合、量化评估的目的。

关键词：软件质量评估,代码审查,缺陷分布

参考文献

[1]朱三元.软件质量及其评价技术[M].北京:清华大学出版社, 1990.

[2]ISO/IEC9126.-1:Information Technology-Software Product Quality-Part1:Quality Mode1.ISO/IEOJTC1/SC7/WG6, Junio, 1998.

[3]陈军, 马溪骏.软件质量审查技术及其进展[J].电子质量, 2004 (1) .

[4]孙梦, 宋晓秋, 巢翌.软件程序代码质量度量技术研究[J].计算机工程与设计, 2006 (2) .

[5]袁玉宇.一个实用的软件质量评估模型[J].计算机工程, 2003 (5) .

[6]Deutsch M, Willis R.Software Quality Engineering.Englewood Cliffs, NJ:Prentice-HaH, 1988.

[7]Boehm B W, Brown J R.Quantitative evaluation of softwarequality[C].2ndInternational Conference on software Engineering, IEEE Computer Society, 1979.

[8]刘, 原林.软件质量度量研究及其分析[J].开发研究与设计技术, 2007 (18) .

软件质量控制方法 篇8

关键词：计划,实施,检查,总结,软件,质量,管理

软件质量控制是软件企业和开发团队能够成功地开发出满足客户需求的软件产品的有力保证。它贯穿于软件项目开发过程的各个环节, 涉及到软件开发的各个部门。只有在软件开发的各个阶段, 对软件开发过程的所有活动及所涉及的各个组织和人员都实行严格的质量控制, 才能够保证软件开发过程的正确性和有效性, 最终才能生产出高质量的软件产品。

软件质量控制的方法主要有目标问题度量法、风险管理法和PDCA循环法。本文主要讨论PDCA循环法的内涵、PDCA循环法对软件项目质量管理的控制参数及PDCA循环法在软件项目质量管理过程中的实施。

1 PDCA循环法的内涵

PDCA循环法中的PDCA是英文计划 (Plam) 、实施 (Do) 、检查 (Cheor) 、总结 (Actiom) 四个单词第一个字母的组合, 它是由美国质量管理专家Deming博士提出来的, 所以又称为Deming循环。

PDCA可用四个阶段 (计划、实施、检查和总结) 八个步骤来说明, 这四个阶段构成了一个完整的圆环。

1.1 P (Plan) 阶段——计划阶段。

这个阶段的工作内容包括四个步骤:第一步, 分析现状, 找出存在的质量问题;第二步, 分析产生质量问题的各种影响因素;第三步, 找出影响质量的主要因素 (称为主因或要因) ;第四步, 针对影响质量的主要因素, 制定对策和计划。计划和对策的拟订过程必须明确以下几个问题:a.Why (为什么) , 说明为什么要制定各项计划和措施。b.Where (哪里干) , 说明在什么地点进行。c.What (干到什么程度) , 说明要达到的目标。d.Who (谁来干) , 说明措施的主要负责人。e.When (何时完成) , 说明完成措施的时间。f.How (怎样干) , 说明如何完成此项任务。

以上六点, 也称为“5W1H”技术。

1.2 D (Do) 阶段———实施阶段。这个阶段只有一个步骤:第五步, 实施计划, 即按照计划的要求去做, 执行计划采取的措施。

1.3 C (Check) 阶段———检查阶段。第六步, 检查效果, 即根据计划的要求, 检查实施执行的结果, 看是否达到预期的目的。

1.4 A (Action) 阶段———总结阶段。

这个阶段包括两个步骤:第七步, 总结经验, 巩固成绩。根据检查的结果进行总结, 把成功的经验和失败的教训纳入有关的标准、规定和制度中, 指导今后的工作;第八步, 把没有解决的问题或新出现的问题转入下一个循环。

2 PDCA循环法对软件项目质量管理的控制参数

在软件项目质量管理过程中, 对软件产品产生影响的参数有三类:产品、过程和资源。PDCA循环法对这三类参数进行综合的调节和平衡。

2.1 产品。

产品是软件开发过程所产生的结果, 它可以是软件生命周期中某一过程的任何输入和输出, 也可以是对最终产品的需求、最终产品本身、开发过程中产生的任何中间产品。如软件系统、软件开发计划、系统规格说明、软件设计文档、差错报告、测试结果等。

2.2 过程。

过程是为完成开发、维护和为保证软件质量所进行的管理和技术活动。如项目立项申请、资源选择、监控开发进展、配置管理、开发初样、设计评审等。

2.3 资源。

资源是为得到要求质量的软件产品, 在实施过程时所使用的时间、资金、人和设备。如软件开发设备、软件测试设备、系统硬件、资金等。

PDCA循环法通过计划来确定质量目标, 定义质量控制参数;通过实施来开发质量, 度量质量控制参数;通过检查来评估质量, 评估质量控制参数;通过总结来提高质量, 改变质量控制参数。

3 PDCA循环法在软件项目质量管理过程中的实施

软件项目开发阶段分成预开发、开发和维护三个阶段。

3.1 预开发阶段。

预开发阶段是指系统开发之前所发生的与系统的获得有关的一切活动。客户通常要完成建立需求的研究、发布招标请求、进行资源选择、与系统开发者签订合同等一系列活动。

客户的工作体现在下列PDCA循环中:a.计划:计划要采用的质量控制过程;在可用资源、已认识到的风险或困难、经验和资金的基础上, 制定选择开发组织的标准;选择已获得证实的、效果较好的软件工程技术工具和方法。b.实施:制定开发招标提案请求包, 包括软件功能和质量需求规格说明、任务描述、资源选择的标准、招标书评价的指导、进度计划数据和将来应提交的产品的要求等。c.检查:检查招标提案请求包的质量, 必要时采取措施进行改进, 并针对不同开发组织对招标提案请求包的反应情况, 对照选择的标准, 选择一个开发组织。d.总结:根据对开发组织、开发过程的选择以及已认识到的风险和困难、可用资源等情况, 提出改善质量控制的计划。

开发组织针对招标提案请求包作出反应, 工作体现在下列PDCA循环中:a.计划:提出要开发的中间产品。b.实施:开发自己的技术提案, 阐明将使用的技术及所拥有的技术工艺。c.检查:提出检查软件质量、纠正产品中缺陷的方法。d.总结:根据检查结果, 提出改善质量控制的计划。

3.2 开发阶段。

开发阶段是指从软件产品开发开始, 到移交产品且客户对软件性能予以肯定为止。这一阶段的PDCA循环活动有:a.计划:开发者根据需求和风险, 提出详细的开发过程、要求使用的资源以及要得到的产品。b.实施:由开发组织执行开发计划。c.检查:开发组织和客户共同检查计划与预期得到的结果的一致性。d.总结:开发组织根据检查结果, 审查并重新认识风险, 作为下一个循环的基础。

3.3 维护阶段。

维护阶段是修复软件缺陷、提高软件性能的阶段。这一阶段的PDCA循环活动有:a.计划:制定处理缺陷的计划。b.实施:处理缺陷, 或根据需求变化提高软件性能。c.检查:开发维护目标是否已经达到。d.总结:根据检查结果, 审查并总结。

由此可见, “计划-实施-检查-总结”这几个基本要素, 在每个软件开发阶段都要不止一次地、循环地应用, 以实现那个阶段的质量目标。在每一个阶段, PDCA循环活动各形成一个小循环。而从整个产品的开发来看, 预开发阶段是这四个基本要素中的“计划”, 在开发阶段和维护阶段, “实施”计划的各种开发或维护活动, 同时进行“检查”, 若发现不满足需求, 则要采取“总结”措施。这是一个大循环过程。PDCA循环法就是这样一个大环带小环, 大环套小环, 周而复始的过程。在软件项目质量管理过程中, PDCA每经过一次循环, 一些问题就会得到解决, 软件质量水平和管理水平就得到了不断的改进和提高。

参考文献

[1]朱少民.软件质量保证和管理[M].北京:清华大学出版社2, 007.

[2] (以) 加林 (Galin, D.) .软件质量保证[M].王振宇等, 译.北京:机械工业出版社2, 004.

软件质量控制方法 篇9

医院卫生装备的质量控制涉及卫生装备的申报、论证、采购、验收、使用、维修、淘汰报废等全寿命质量管理过程,它包括医学计量和卫生装备质量控制两大类。为了实现我院卫生装备质量控制的全程数字化管理,我们对原有采用PB6.5做前台开发工具,Oracle为后台数据库,以C/S结构开发的计量管理软件进行了全面的改进和升级。新系统采用B/S(浏览器服务器)的模式构建。B/S模式是一种以Web技术为基础的新型信息系统平台模式,其用户界面主要是通过网络浏览器呈现,基本逻辑均在服务器端实现。与传统C/S(客户端/服务器)模式相比,具有快速的应用更新、易于维护、集成资源共享等优点。该模式采用多层次网络系统,以实现各层间网络互联。通过挂接“军字一号”,进行受控设备的档案、采购、维修和质控、计量等数据信息共享、传输与实时更新;并将条形码管理技术和PDA技术运用进来。其中,条形码用以实现对受控设备的统一编码管理,即质控编号和设备档案条形码一致,建立网络化信息数据库,容纳所有受控设备的电子档案,以实现涵盖全程管理环节的追溯式记录与管理;PDA技术用于实现随时随地查询受控设备的档案及历史受检信息,记录检测原始数据,并对数据进行存储、计算、处理,快速判断检测结果,自动生成检测证书,从而提高检测效率和质量。另外利用同步传输功能亦可将PDA中的检测数据传输到台式机的软件系统中,以实现检测数据的更新、统计、分析和查询。同时,本软件采用Windows Server 2003及SQL Server 2005 Express作为服务器平台,利用Visual Studio 2005及.NET Framework 2.0开发包,并调用Office PIA组件实现数据统计。SQL网络数据库的使用,可大大提高数据处理能力。

本软件可以实现受控设备的档案管理、大型医疗设备的“三证”管理;智能提醒到期设备,实现过程监管;数字化记录检测信息,以完成受控设备检测数据的记录、跟踪、查询、深层次挖掘分析与统计,智能输出各类质控标签与证书;检测人员档案管理、信息查询、检测工作量统计等。

2 软件的总体结构与功能模块

卫生装备质量控制全程管理可分为3个阶段:即入库前质控验收、建档和标识阶段,周期性质控溯源、检测和管理阶段,卫生装备维修、淘汰和报废阶段。本软件主要包括受控设备质量控制管理模块、受控设备检测报告管理模块、检测人员管理模块,查询与统计管理模块。总体结构如图1所示。

2.1 受控设备质量控制检测管理模块

受控设备质量控制检测管理包括新设备验收检测管理、周期性质控检测管理、修后设备质控检测管理、选型检测管理几个部分。根据我院卫生装备计量与质量控制检测及本院所承担的检测项目等不同,按受控类别分为:一级医学计量检测、二级医学计量检测、三级医学计量检测、地方医学计量检测、大型医疗设备检测、质量控制检测。根据各委托检测单位的不同对受控设备进行分类。

2.1.1 新设备验收检测

首先在系统数据库中建立受控设备品种管理目录,设备签订采购合同后,一经采购部将合同信息录入到合同管理系统中,系统会根据目录自动判断该设备是否需要质控。质控管理员也可在合同管理系统中进行手动筛选,这样做是为了避免因设备存在别名而造成误判。设备到货后,质控管理员进行到货确认和入库登记。然后分配检测任务,其中属于三级医学计量检测和质量控制检测等医院有自检能力的设备,由本院质控检测人员承担(一周内需检测完毕),其他的由质控管理员及时送检或请外单位检测(一个月内完成检测)。经自检合格的受控设备需贴记检测标识、检测信息登记等。同时通知库房出入库、档案室打印设备条形码,然后受控设备出库领用。通过质控验收检测的新设备会自动进入系统数据库中,进入周期检测管理。若新设备经检测不合格,质控室需及时通知采购部安排退换。新设备验收检测流程如图2所示。

从本软件投入运行开始,所有验收检测后的新设备均需质控编码,以逐步实现全院受控设备的数字化管理。受控设备质控编号即是对受控设备建立检测信息的由计算机编制的质控条形码,每台受控设备对应一个编码,经激光扫描或输入设备质控编号至PDA中即可进行身份识别,查询设备档案信息、使用状态、历史维修记录、历史受控信息及检测记录等。质控编号原则,以心外科的呼吸机为例:HXJ-ZK-001,由系统按顺序自动生成。

合同信息包括:使用科室、设备名称、拟到货日期、规格型号、数量、金额、生产厂家、代理公司。

到货登记包括:送检人(送货人)、送检日期(到货日期)、机身号、生产日期、质控编号、受控类别、检测费用(收入/支出)。

请领登记包括:请领日期、档案号、请领人、联系电话。

质控检测包括:检测报告编号、检测日期、检测人、检测单位、检测周期、检测结果。

对大型医疗设备进行验收质控检测记录中还需登记其配置许可证编号、应用许可证编号、操作人员上岗证等“三证”信息。

当新购买的设备入库后,系统会自动判断该设备为质控检测设备,不需选择,直接从数据库中将质控检测设备导入到质控检测设备基本表中,新验收设备质控检测时的相关SQL

语句为:

CREATE TRIGGER[tg_qual Mea Arc]ON[dbo].[b Equi Arc]

FOR INSERT,UPDATE

AS

begin

declare@equi Name varchar(50)declare@qual Mea Sign

varchar(50)declare@qual Mea ID int declare

@qual Mea Num varchar(50)

declare@equi ID int declare@equi Spell varchar(50)declare@equi Name ID int

declare@arc Num varchar(50)declare@equi Spec varchar(50)declare@model varchar(50)declare@facu int declare@fact int declare@model ID int

declare@fact Num varchar(50)

qui Name,

@qual Mea Sign=vchr Is Measure,@arc Num=vchr Arc Num,

if(@qual Mea Sign='质控')

2.1.2 周期性质量控制检测

周期性质量控制检测的设备包括两类:一类是万元以上已进入设备档案管理信息系统中的设备,这类设备可以通过关键字查询,直接从“军字一号”获取设备的档案信息,质控建档;另一类是万元以下没有进入档案管理的小设备,由质控管理员对该类设备进行档案信息登记和质控建档管理。本软件具有自动提醒功能,根据受控设备所属的受控类别,分别提示该类仪器设备的到期情况,如图3所示。在用的且属于医院自检的受控设备到检测期限时(停用或报废设备不检测),由质控管理员将检测任务进行分配;外检和送检的仪器设备则由管理员及时送检,检测后登记检测信息和填写检测原始记录,出具检测证书。不合格的设备则由质控管理员发出维修通知至维修管理系统中。设备停用或经多次维修、检测仍不合格的受控设备则予以停用、淘汰和报废,同时将设备状态修改为停用或报废,该设备就不会再被计入。但其档案信息、历史质控信息仍可以查看。周期性质量控制检测流程如图4所示。

受控设备档案信息包括:使用科室、设备名称、档案号、规格型号、生产厂家、金额(元)。

受控设备质控建档包括:受控类别、质控编号、机器号、检测周期、检测单位、上次检测日期、上次检测结果、设备状态(在用、停用、报废)、上次检测报告编号、填写上次检测记录。

质量控制检测包括:检测日期、检测人、检测结果、检测费用(支出)、设备状态(在用、停用、报废)、检测报告编号、填写检测记录。

对大型医疗设备质量控制检测信息中还需记录配置许可证编号、应用许可证编号。

关键字:按使用科室、设备名称、档案号、设备号、质控编号查询。

在周期性质量检测时,系统会根据条件查询到所指定要检测的受控设备基本信息及历年检测详细数据信息。相关SQL语句为:

a Basic(true,this.Text);

(efrm Qual Mea Basic_eve Qual Mea);

2.1.3 修后质量控制检测

本系统与维修管理软件相挂接,凡是通过验收检测或周期性质量控制检测后的设备都会在系统中自动生成受控标识,若该设备一经维修登记,系统将自动发送修后检测通知给质控管理员,实现对维修后设备的监控,检测完后该设备的质控到期时间将被重新计算。对维修后经质量控制检测不合格的受控设备质控管理员会再通知维修人员维修,直到检定员检测合格为止;经多次维修、检测仍不合格的受控设备则通知维修部降级、淘汰或报废,质控室及时清理质控账目。修后质量控制检测流程如图4所示。

2.1.4 选型检测管理

选型检测管理主要是针对拟投标或拟采购的设备进行应用质量选型评价的质控检测,其流程类似于验收检测,只是该被检测的设备不会计入到档案库中。

2.2 受控设备检测报告管理模块

检测报告管理包括检定规程与技术规范的上传、下载,检测原始记录的下载、录入、浏览、查询和打印、检测证书的自动生成及打印等,分别就受控设备验收检测、周期检测、修后检测的信息进行查询与浏览。检测报告填写界面如图5所示。

检测原始记录:实现质控检测数据的数字化管理,填写完成后可自动生成Word文档,免去繁琐的手写记录,同时可以添加数字签名以验证记录的法律效应;记录检测信息,检测数据输入后,系统会自动判断检测指标,提高检测效率,这些数据是进行设备应用质量分析的数据基础,说明受控设备的质量运行状况,使用管理情况等,从而找出影响受控设备质量的主要因素,提高设备的合格率和使用寿命,以期对采购的论证选型、维修的质量评估及使用科室合理使用提供参考指标。

2.3 人员管理

对计量、质量控制检测人员及质控监督员建立人员档案信息管理数据库,进行人员档案管理、检定员证、培训记录等管理。

2.4 查询和统计管理模块

受控设备查询与统计是指对常规受控设备的档案信息、检测信息等一些受控指数的统计分析,所有结果均可导入到Excel或是Word中,以便数据处理。

(1)基本信息:可查询受控设备的档案信息、质控检测基本信息及大型医疗设备三证等。

(2)质控汇总:各检测类别中待检、已检、未检、停用、报废、到期及过期设备的数量和详细信息,检测人员工作量,可就全年各受控类别的检测费用支出与收入情况进行统计。

(3)指数统计:可按科室、受控类别及时间等方式,查询统计受检台数、受检率、合格数、合格率、不合格率、检测人员检测工作量统计等。

(4)数据分析:根据质量控制检测的性能参数进行查询和分析某种设备的检测情况(具体参见各检测记录)。通过选择受控设备的品牌或型号进行统计和分析,并对其技术参数进行分析和对比,还可以进行科室受控情况进行统计与分析。

3 总结

卫生装备质量控制管理软件,将设备管理信息系统与质控/计量管理系统结合:将质量控制工作与采购、档案、维修、计量相结合,实现卫生装备全程生命周期(life cycle)的信息化管理。随着总部要求开展的卫生装备质量控制检测项目的不断增加,尤其是X线类等其他设备检测能力的逐步下放,势必会造成检测工作量与难度的加大。本软件的实施可大大减轻质控管理人员的工作量,提高检测效率、有较强的实用性。与设备档案管理系统共享设备档案数据库免于重复录入、直接获取军字一号上的设备信息;界面直观可视,准确及时地反映医院卫生装备质量控制检测工作的实施情况,定时提醒功能确保卫生装备质控检测周期计划的完成、防止漏检;原始记录的数字化,实现真正的质控数据数字化输入管理,可以免去繁琐的手写记录,用数字签名来验证记录的法律效应;更多的统计与分析,在数字化原始记录的基础上,实现数据挖掘功能,通过对受控设备技术参数等检测数据的分析、评价与定期通报,以数据说话,为临床科室科学使用、职能部门有效采购、管理部门监督管控高风险卫生装备等提供参考信息和评价指标,如通过输液泵的检测和临床科室的沟通反馈,从而找出适合我院临床使用的输液管路品牌、规格型号及使用注意事项等,这对于提高在用设备的使用效率和寿命,提高医工科在全院中的地位都起到很好的作用。

摘要：目的:建立医院卫生装备质量控制的全程信息化跟踪管理模式。方法:依据医院卫生装备质量控制的管理流程,将卫生装备的采购、维修、档案、质控等部门通过“军字一号”联网。结果:解决了原有计量管理软件无法对新购进、维修后并要求质控检测的仪器设备进行控制和检测;对使用中设备的应用状态不能进行状态评估、过程监管、质控跟踪、到期提醒,检测数据的深层次挖掘、分析和评价等问题。结论:该管理软件的应用可以大大提高受控设备的检测效率,增加卫生装备的使用寿命和监督管理,从而提高医工科在医院中的地位和作用等。

关键词：卫生装备,质量控制,软件,设计,应用

参考文献

[1]郑焜,谢松诚.医疗设备的循证管理[J].中国医疗器械信息,2009,15(8):41-49.

[2]汤黎明,吴敏,于春华.医疗设备质量控制体系建立的探讨[J].解放军医院管理杂志,2008,15(1):31-33.

[3]种银保,郎朗,黄燕.现代医疗设备管理现状及其发展趋势[J].医疗卫生装备,2009,30(3):86-90.

[4]张金葆,刘文,卢爱国,等.医疗设备质量安全检测体系的建立[J].现代医院管理,2009,24(6):78-80.

软件配置管理过程控制方法研究 篇10

随着计算机技术的飞速发展, 大量应用软件在各种系统或设备中被安装使用, 为提高各种作业流程的自动化水平发挥了重要作用, 可以说, 没有应用软件支撑, 许多系统都无法运行。在实际应用中, 往往需要针对特殊业务需求或作业流程, 定制或开发专用应用软件, 并根据业务需求变化进行适应性改造与完善。该软件一般需要自行研制开发, 由于应用软件开发涉及到规模大小不同、软件关键性等级不同、软件开发运行环境不同、软件开发人员分工和开发能力等多种因素, 在软件开发和应用管理过程中存在问题较多, 有些问题甚至直接影响到业务运转或作业流程的成败。

(1) 软件工程化规范问题。软件项目实施中, 参加软件开发的人员一般由负责设备管理或具体专业的人员参加, 对软件工程化缺乏深入全面的掌握, 只能边学习、边设计、边实现、边修改, 容易产生软件开发阶段划分不准确、文档拟制不规范、软件文档与实际产品不相符、软件测试不周全等问题。

(2) 软件版本控制问题。自研应用软件开发与应用中, 开发者一般同时也是使用者, 开发环境也是运行环境, 开发人员对负责的设备和业务比较熟悉, 对自己开发的软件也比较熟悉, 在使用过程中更容易发现软件存在的问题和缺陷, 因此往往会随意改动软件, 而不提交软件问题申报单和软件更动报告单, 不进行相应的影响域分析, 更动之后也仅仅只做调试, 不经过严格正规的测试, 会造成潜在的软件危险, 甚至可能直接影响到设备安全。

(3) 软件使用管理问题。不按照软件配置管理和使用规定, 从软件配置管理库中提取正确的软件版本, 或者仅办理软件使用审批手续, 但不清理软件运行环境, 不检查软件版本和运行状态, 仍然会出现实际运行软件不是正确版本、不能掌握软件运行环境和运行状态等问题, 最终可能导致软件配置管理的失控。

1 软件配置管理关键环节

软件配置管理的任务是制定软件配置管理计划, 确定配置标识规则, 实施变更控制, 报告配置状态, 进行配置审核, 进行版本管理和发行管理。

软件配置管理是从软件项目开始直至软件退出运行, 贯穿整个软件生命周期的一组跟踪与控制活动, 本质是标识、组织和控制对正在开发的软件修改更动的技术, 以减少软件更动所需的工作量。其重要性在于:“你不控制变更, 变更就会控制你。”而变更是软件开发过程中不可避免的活动。

熟悉并恰当应用软件配置管理工具, 可以很好地管理软件项目, 但在实施中要真正管理好软件项目, 除了技术手段, 如何对过程进行管理更加重要, 需要把握好几个环节, 一是软件生命周期的合理划分, 二是软件更动控制的管理方法, 三是软件运行版本的管理。

1.1 软件生命周期划分与裁剪

完整的软件生命周期包括系统分析与设计、需求分析、概要设计、详细设计、编码与单元测试、部件测试、配置项测试、系统测试、验收移交与保障、软件维护、软件报废。

对具体的软件项目, 不一定包括生命周期的所有阶段, 要根据软件规模、运行环境、开发环境、安全级别等因素综合考虑, 对具体软件项目进行合理的阶段划分和裁剪。

(1) 仅有一个配置项的小规模软件, 如运行在一台设备中的应用软件, 软件设计不需要划分概要设计和详细设计阶段, 软件部件测试阶段也不需要, 但如果软件关键性等级高, 则需要详细划分各个阶段。

(2) 基于集成可视化的组态软件的设备监控软件开发, 不需要考虑软件单元测试和部件测试阶段, 甚至可以将配置项测试与系统测试合并。

(3) 对于大规模和包含多个配置项的软件, 要划分完整的生命周期阶段, 每个阶段都要提供完整的文档和产品。

(4) 对于软件开发的每一个阶段, 都要进行阶段评审, 软件编码与单元测试、部件测试阶段一般只需要内部评审, 其它阶段需要专业机构或专家组织进行评审。软件配置项和系统测试需要第三方测试。对于软件关键性等级高的软件, 各个阶段都要组织专家评审, 必须经过第三方测试。

(5) 各个阶段都要提交相应的产品和文档, 并严格按照软件配置管理要求进行管理。

1.2 软件更动控制

软件配置管理的根本任务就是有效控制软件更动及其产生的影响, 软件更动产生的影响往往是不可估量的, 因为软件代码中一个极小的Bug可能就会造成设备极大的故障甚至灾难。因此, 必须要严格控制软件更动过程, 防止严重故障或灾难性问题的发生。

(1) 软件问题报告。软件开发人员或使用人员通过填写软件问题报告单向主管机构报告发现的问题, 软件问题报告单要准确描述软件问题名称、软件版本信息、提交问题的人员及时间等, 对软件问题来源 (程序、文档、数据库、设备更新等) 、问题现象和原因也要进行详细描述, 并提出修改要求和修改内容。

(2) 软件更动审批。软件开发人员根据软件问题报告单填写软件更动报告单, 说明软件更动类型 (纠错、改进、扩充等) 和更动项目 (程序、文档、数据库等) , 要详细描述软件更动的具体内容, 进行影响域分析, 说明软件更动对设备、其它软件模块或作业流程的影响, 确保软件更动的正确性, 防止产生负面影响。软件更动报告单要经过软件配置管理机构的审查和批准, 方能实施更动, 如果需要, 还应当进行评审, 以确定是否可以更动, 以及更动的内容和方法是否合适。

(3) 回归测试。软件更动后要进行测试, 编写完整的测试用例来测试更动后的软件。通过测试后, 要按照软件配置管理程序履行软件入库、出库与安装运行手续, 以正确使用更动后的软件。

软件更动本身可能比较简单, 比如只修改一条语句甚至一个字符, 但软件更动的管理过程很复杂, 从提交软件问题、更动、测试到运行需要履行多道手续, 有可能还要经过评审。这一过程的工作量远远比修改软件本身的工作量繁重得多, 因此可以有效防止开发人员随意更动软件行为的发生。

1.3 软件使用过程管理

软件使用过程管理, 既要保障操作人员从配置管理库提取正确的软件版本, 还要检查使用人员是否正确使用软件和使用正确的软件版本, 特别是在自研软件较多的情况下, 必须检查软件使用状态。

(1) 软件使用申请。软件使用人员根据设备运行或作业流程, 在一个特定的阶段开始前, 比如每年或每个季度, 或在设备投入使用前进行设备状态检查时, 填写软件出库申请单来申请使用软件, 说明申请使用的理由和需要使用的软件版本, 经过审批后从软件配置管理库提取软件。

(2) 软件安装使用。软件安装前, 要对软件运行环境进行清理, 包括重新安装操作系统、查杀病毒、删除原来运行的软件版本 (或进行备份) , 重新配置软件运行环境, 以保障软件环境的干净和安全。然后根据软件安装运行的操作规程安装使用软件。

(3) 软件版本比对与检查。软件配置管理机构必须要对操作人员安装的软件进行检查, 以确认是否为申请的软件版本, 这个过程非常重要, 防止使用人员只履行手续而不安装软件, 而是继续运行原来的软件, 对于自研软件, 如果不检查, 可能会出现配置管理库与运行版本不一致而最终导致软件版本混乱的问题。对于固化在PLC中且没有更动的软件, 一般不需要重新安装或固化, 但需要进行软件版本的比对检查, 防止意外情况的发生。

2 软件配置管理过程控制措施

软件配置管理本身是一项保障软件完整性和正确性的技术, 通过管理手段进行软件配置管理过程控制, 则是保障软件开发质量, 保证正确和规范使用软件的基础。

2.1 充分发挥软件配置管理机构的职能作用

按照软件工程规范, 成立软件配置管理机构, 设立软件配置控制委员会, 并下设软件配置管理小组, 明确并履行管理职责。

(1) 软件配置控制委员会负责受控库和产品库中各软件项目配置管理组的成立、配置管理计划、基线设置、配置管理项设置、更动申请、产品出入库等工作的审批, 审查各种表单和提交产品的完整性、一致性和完备性, 核实配置管理落实情况, 确保软件与产品库的一致。

(2) 软件配置管理小组在软件配置控制委员会的领导下, 负责软件配置管理的组织计划与协调, 管理软件配置管理专用系统设备工具, 检查软件配置管理履行手续, 对软件配置管理项及其存储介质进行日常维护管理。

2.2 定期清理软件技术状态

(1) 依据软件配置管理库, 建立软件配套表, 清理软件文档和软件版本, 以保证软件文档齐全规范, 软件版本和文档控制号正确。

(2) 通过代码清查分析等方式, 确认和熟悉软件版本、编程结构及编程方法。

(3) 对软件运行环境进行清理, 对具备病毒查杀条件的计算机进行病毒查杀, 检查机器硬件、操作系统和相关系统软件的工作状态、磁盘存储容量、余量, 清理多余文件和数据。

2.3 检查软件配置管理状态

(1) 检查软件配置管理库中的软件状态, 重点清查应用软件的版本号、文档控制号等, 对软件版本的一致性进行检查, 确保软件源程序和执行代码的一致性, 避免入库源代码与执行代码不对应。

(2) 清理系统应用软件更动情况, 检查软件问题报告、更动报告、回归测试报告等入库情况和软件配置库的完备性。

(3) 对配置管理库中软件配置管理情况进行审计, 保证程序与文档、文档与文档及产品与要求的一致性符合软件工程化技术标准要求。

2.4 软件出库安装和运行检查

(1) 检查应用环境中所安装的操作系统、参数设置与软件用户手册要求是否一致。

(2) 检查应用环境中各系统软件安装、参数设置与软件用户手册的要求是否一致。

(3) 对所有纳入配置管理的软件进行出库安装和运行检查, 逐个安装应用软件并运行检查, 检查各软件功能和性能, 考察软件的正确性和稳定性。

2.5 对嵌入式软件进行比对分析

针对嵌入式软件随设备固化、运行状态隐蔽等特点, 进行出库比对, 重点从运行版本与出库版本的一致性、参数设置的一致性等方面进行比对分析, 确保软件运行稳定可靠。

3 结语

本文针对自研应用软件开发与使用管理中存在的问题, 分析讨论了软件配置管理过程中需要注意的几个环节, 总结了软件配置管理的过程控制方法和有效措施, 以保证软件工作规范有序、软件版本正确、性能稳定、软件开发符合规范要求、软件使用和更动过程受控, 从而有效保障了软件在生命周期内状态的完整性、一致性和可追踪性。

参考文献

[1]邓成飞, 李洁.软件工程管理[M].北京:国防工业出版社, 2000.

[2][美]ROGER S PRESSMAN.软件工程:实践者的研究方法[M].梅宏, 译.北京:机械工业出版社, 2002.