质量控制软件

质量控制软件（精选12篇）

质量控制软件 篇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

发动机试车控制软件工程化及质量管理

为提高发动机试车控制软件的可靠性.通过需求分析、概要设计、详细设计、软件测试等步骤实现了软件开发工程化.结合试验控制软件研制和使用特点,对软件质量管理的具体步骤,即从设计评审、测试、验证、文档及技术状态管理等方面对软件开发过程进行监督与管理,实现了软件开发的质量控制,达到了软件设计的透明性、继承性及高可靠性.

作 者：蒋瑜 王秋红 Jiang Yu Wang Qiuhong 作者单位：西安航天动力试验技术研究所,陕西西安,710100刊 名：火箭推进英文刊名：JOURNAL OF ROCKET PROPULSION年，卷(期)：34(4)分类号：V434.3关键词：火箭发动机 试验 控制软件 可靠性 质量管理

电子政务系统软件质量评价软件 篇3

本项目通过对外部质量的研究结合电子政务系统的特点构建出电子政务系统软件的质量评价模型，并引入六西格玛质量管理理论作为质量评价模型各个指标的度量标准。给予各个评价指标适当的权重，结合指标数据和相应的权重进行计算，最终得出电子政务系统的评价分数。

关键词：电子政务；六西格玛；质量评价模型；外部质量

中圖分类号：TP393.08

本课题依据中国国家标准化管理委员会发布的软件工程产品质量标准对电子政务系统软件的外部质量进行分析、评价和处理，外部质量是基于外部视角的软件产品特性的总体，即当软件执行时，典型地是在模拟环境中用模拟数据测试时，使用外部度量所测量和评价的质量。通过对外部质量的研究结合电子政务系统的特点就可以构建出电子政务系统软件的质量评价模型，采用基于质量评价模型的电子政务系统软件的测试数据作为输入数据，并引入六西格玛质量管理理论作为质量评价模型各个指标的度量标准，量化各个指标。参考电子政务标准化指南和电子政务系统总体设计要求，给予各个评价指标适当的权重，结合指标数据和相应的权重进行计算，就可以得出电子政务系统的评价分数和等级。

1 需求分析

1.1 系统业务功能

本系统分为系统事件流程，客户事件流程和管理员事件流程三个功能集合。系统事件流程分为系统登陆、用户个人信息修改、系统退出、客户注册四个功能。客户事件流程分为系统信息提交、评价信息提交、系统成绩计算、评价成绩查询四个功能。管理员事件流程分为客户管理、评价系统管理、评价项目管理三个功能。

1.2 主体模型分析

1.2.1 外部质量指标。本质量评价模型主要通过对电子政务系统的外部质量的考察而设立指标。外部质量指标是从用户使用角度去总结软件产品特性，并加以分类和细化，制定相关的考核等级和标准。

1.2.2 权重分析法。不同外部质量指标对于评价体系的意义是不同的，指标的权重可以在决策中相对重要程度综合度量在主观评价和客观反映。

1.2.3 六西格玛质量管理理论。西格玛在统计学中用来表示标准偏差，用"σ"度量质量特性总体上对目标值的偏离程度。六西格玛流程能力（短期）可解释为每百万个机会中有3.4个出错的机会，即合格率是99.99966%。

2 系统设计

2.1 总体设计

2.1.1 模型指标设计。（1）功能性。包括准确性，适用性，互操作性，安全保密性，指在指定条件下使用时，电子政务系统提供满足明确和隐含要求的功能的能力；（2）可靠性。包括容错性，成熟性，易恢复性，指在指定条件下使用时，电子政务系统维持规定的性能级别的能力；（3）易用性。包括易操作性，易理解性，易学性，指在指定条件下使用时，电子政务系统被理解、学习、使用和吸引用户的能力；（4）维护性。包括易分析性，易改变性，稳定性，易测试性，指电子政务系统可被修改的能力。修改可能包括纠正、改进或软件对环境、需求和功能规格说明变化的适应；（5）可移植性。包括适应性，共存性，易替换性，指电子政务系统从一种环境迁移到另外一种环境的能力。

2.1.2 成绩计算方法。第一步，对每个指标的度量值采用六西格玛质量管理度量理论进行评分，

具体实现方法如下：

√ 当Xi=1时，Pi=100，说明该评价度量指标完全合格；

√当0.9999966≤Xi<1时，Pi=90，说明该评价度量指标达到六西格玛质量标准。

√当0.9999767≤Xi<0.9999966时，Pi=80，说明该评价度量指标达到五西格玛质量标准。

√当0.999379≤Xi<0.9999767时，Pi=70，说明该评价度量指标达到四西格玛质量标准。

√当0.9933193≤Xi<0.999379时，Pi=60，说明该评价度量指标达到三西格玛质量标准。

√当0≤Xi<0.9933193时，Pi=0，说明该评价度量指标达不到最低标准，不合格。

其中，Xi为第i项评价度量指标的度量值，Pi为第i项评价度量指标经过六西格玛质量管理度量理论处理后的值。

第二步，采用综合评分分析法计算出经质量评价模型度量后的系统总得分，

公式为I=∑PiWi（1≤i≤n）

其中，Pi为第i项评价度量指标经过六西格玛质量管理度量理论处理后的值，Wi为第i项评价度量指标的权重，I为该系统的总得分。

第三步，算出该系统的总权重和，公式为II=∑Wi（1≤i≤n）

其中，Wi为第i项评价度量指标的权重，II为该评价模型的总权重和。

第四步，用系统总得分除以总权重和，就可以得出该系统的百分制得分。公式为S=I/II

其中，I为该系统的总得分，II为该评价模型的总权重和，S为该系统的百分制得分。

4 总结和展望

电子政务系统质量评价软件的实现重点是质量评价模型的构建。本系统的质量评价模型主要通过对电子政务系统的外部质量的考察而设立指标，从功能性、可靠性、易用性、维护性和可移植性五个方面进行考察。每个方面都设置一系列度量指标，从不同角度考察电子政务系统在该方面的综合表现。度量指标由于评价软件的特性不同，其重要性是不一样的。我们参考电子政务标准化指南和电子政务系统总体设计要求，根据电子政务系统的特点设计出不同指标的权重，设计出真正考察电子政务系统质量的评价模型。

度量指标是评价的工具，是反映评价对象属性的指示标志；指标体系，则是根据评价目标和评价内容的要求，构建的一组相关指标，据以搜集评估对象的有关信息资料，两者缺一不可。基于电子政务系统的软件特性，我们可以把电子政务系统软件的测试数据作为度量的对象。对应电子政务系统质量评价模型中的各个指标，收集相关的测试数据作为质量评价软件的输入数据，通过度量标准定量得出该评价指标的优劣。本质量评价模型采用六西格玛质量管理理论作为指标的度量标准，提高了电子政务系统质量评价系统的科学性、先进性。

本软件的初步开发工作已基本完成，后续优化阶段已经在准备当中。提高软件的访问性能，优化质量评价模型，提高系统的安全性和可靠性等问题将在下阶段的开发过程中解决。通过对本软件特性和功能的认识，我们相信本电子政务系统质量评价软件一定会为我国电子政务事业做出应有的贡献。

参考文献：

[1]GB/T 16260.1-2006/ISO/IEC9126-1.Software engineering-Product：Quality model[S]，2006.

[2]GB/T 16260.2-2006/ISO/IEC9126-2.Software engineering-Product：External metrics[S]，2006.

[3]GB/T 16260.3-2006/ISO/IEC9126-3.Software engineering-Product：Interior metrics[S]，2006.

[4]GB/T 16260.4-2006/ISO/IEC9126-4.Software engineering-Product：Quality metrics[S]，2006.

[5]GB/T 21064-2007.System general design requirements for electronic government[S]，2006.

[6]杨安.电子政务规则与案例解析[M].太原：山西人民出版社，2005.

作者简介：王梦雷（1985.12-），男，天津人，助理工程师，本科，研究方向：系统架构设计。

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

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

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结束语

软件课程教学质量分析 篇5

本第一学期软件技术专业专业课程主要授课对象为软件1601班，软件1601班15人，上一学年学习了相关专业基础课程。本学期重点讲授移动应用开发专业课程：《移动应用开发基础》，《移动应用高级开发》，《移动应用开发项目实战》，三门课程分阶段实施。根据课程内容，精选多个项目，将知识点融入到实际项目中，由浅入深，由易到难，最终通过项目考核完成三门核心专业课程的考核。过程性考核覆盖移动应用开发的基础知识、基本技能、基本方法，同时注重项目开发的考察，关注学生的项目分析能力的培养，具体体现在：

一、项目化特点

1.内容覆盖面广，对每一部分内容均有涉及，有利于全面考察学生的知识和能力，突出了重点。加大了难度，有9分是超教材的内容。

2项目综合性强，考察了学生思维，运用不同知识点的灵活性。

二、学生完成情况分析

1.界面多数能够实现，UI部分使用线性布局或者嵌套布局，较简单，可实现 2.基础功能，比如按钮触发，容易理解，容易记忆 3.数据存储逻辑性强的，很难实现 4.多个功能组合难于实现

三、今后教学改进措施

通过本学期实际执行情况分析我们的教学现状，在今后的教学与评价过程中应作如下几方面的工作：

1、严格遵循教学规律，严控项目开发过程。在项目化教学理念指导下，把项目当作学生学习的基本素材，重视项目中所蕴藏着的更为丰富的教学资源，善于驾驭项目中涉及的基础知识点，能从学生的年龄特点和生活经验出发，组织学生开展有效地项目项目知识点学习。

2、营造和谐的环境，引导学生主动学习。

教学中教师要发扬教学民主，保护每个学生的自尊心，尊重每个学生独特的富有个性的见解，引导学生的主动参与、亲身实践、独立思考、合作探究，改变单一的记忆、接受、模仿的被动学习方式，发展学生搜集和处理信息的能力。

3、结合具体的教学内容，渗透项目开发方法。

在课堂教学中，教师要意识渗透项目开发方法，引导学生自觉地检查自己的思维活动，反思自己是怎样发现和解决问题的。

4、做好帮差补缺工作。

在教育教学中培养优生的同时，更重要的是进一步加强后进生铺导，真正做到全面提高教育教学质量。

四、通过本学期的教学质量分析，使我认识到在今后的教学中应做到：

1、加大项目的训练，多加强学生语项目分析及实战训练。

2、以后多选择更加贴近学生生活的项目案例让学生练习。

3、培养他们分析问题，选择设计方法的能力。

4、培养他们善始善终做项目的好习惯。

5、多鼓励学生，培养他们爱学习，爱项目开发的自信心。

关于软件质量提高的探讨 篇6

关键词：软件质量；评价；标准；提高

中图分类号：TP311.5

1 软件质量的评价标准

软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。影响软件质量的主要因素，可划分功能性、可靠性、易用性和安全性。

1.1 功能性。是与一组功能及其指定的性质有关的一组属性，这里的功能是指满足明确或隐含的要求的那些功能。性能不仅仅是指软件的运行速度而已，通常意义上是指软件的时间-空间效率。性能优化的关键工作是找出限制性能的因素可以通过优化数据结构、算法和代码来提高软件的性能。是与一组规定或潜在用户为使用软件所需做的努力，和对这样的使用所做的评价有关的一组属性我们要做的是从量化的角度改善软件工程，最终改善软件质量。

1.2 可靠性。是指在特定的时间和条件下，该种软件能够平稳维持其性能、能力有关的一组属性。是指在一定的环境下，在给定的时间内，系统不发生故障的概率。也是在异常情况下，软件能够正常运行的能力。有些开发者往往不能分辨出异常情况，以至于导致可靠性降低。对于软件来说，可靠性包括容错能力以及出现问题之后的自我恢复能力就，如何提高软件的可靠性是开发者的义务。

1.3 简便易用性。是指用户使用软件的容易程度。来保证“界面友好”、“方便易用”。易用性表示该软件的所有工作成果在用户使用过程中易读、易理解，这种情况下，在软件投入使用之后可以提高团队开发效率，降低维护代价。

1.4 安全性。安全性是指信息安全，是指改软件产品在互联网信息大融合的情况下防止系统被非法入侵的能力。开发商和客户愿意为提高安全性而投入的资金是有限的，现代软件产品有很多都采用“增量开发模式”，不断推出新版本，以此来获取增值利润。但在追求利益的同时一定要保证可扩展性，可扩展性是系统设计阶段重点考虑的质量属性之一。

2 关于提高软件质量的注意事项

2.1 软件的性能，软件研发在进行需求调研时，不但应该更多的获取功能或者业务的要求，而且对于客户在软件系统响应或者并发等方面的要求，可以据此定义出软件系统的性能方面的要求.这些要求在实现过程中应该具体的被表现在开发，测试等文档中.而且针对此类性能需求的深入分析。

2.2 软件系统维护，扩充方面的需求.在进行系统功能调研和分析时，要对客户业务的规模，以及客户的发展等各方面情况有更清楚了解.可以根据这些信息更好的进行软件功能点划分，硬件设备选型等工作.軟件系统如何能更好的实施也是软件质量非常重要的一个环节。

2.3 非功能性的需求很多时候需要考虑硬件以及网络方面的成本。针对这些问题需要与客户进行良好的沟通，设定合理的非功能性目标，在成本与质量方面要有良好的平衡。

2.4 提高软件质量是整个研发团队的任务，每个小组都应该为这个目标做更多的工作.但现实的软件研发过程中往往简单的将软件质量问题归咎于软件测试或质量保证部门.软件测试不可能发现所有的软件缺陷，要想提高软件的质量，那么整个团队要付出更多的努力.研发过程中越早进行质量的控制，软件质量就会越好.整个团队强烈的软件质量意识，是保证软件软件质量的关键。

3 保证软件质量的几点措施

如何保证软件的质量，从一个企业的长远发展来说，首先应当从流程抓起，不断规范和完善软件产品的开发过程。这是从根本上解决质量问题，提高工作效率的一个关键手段。

3.1 质量改进需要花费成本，因此改进的途径需要视不同公司的规模等多方面综合进行考虑。满足业务需求，提高用户体验满意度，没有了不切实际的需求和质量要求，那么团队确保质量的能力也就提高了，质量标准的定义还要考虑时间、资源、预算等因素。中型以上的较大的软件公司可以实施CMM体系。

3.2 提高需求分析和设计方面的技术，加强文档化工作。一个高的质量要求需求规格说明书足够详细，以便产品可以根据这些规格说明书进行定量的分析，对于一个企业要想获得长期的发展，必须加强文档化工作；加强编程规范工作；进行适当的测试工作，建议进行单元测试和系统测试；实施配置管理工作，加强版本控制；开展走读、评审和检视活动，尤其要加强代码走读，建议进行每日交叉走读活动；进行简单的度量分析获得。

3.3 软件产品的开发同其它产品的生产有着共同特性，即需要按一定的过程来进行生产。对于软件开发来说，要保证软件的质量，需要掌握多方面的技术，包括分析技术、编码技术、和测试技术等，流水线生产方式被证明是一种高效且能够比较稳定地保证产品质量的一种方式。不同的人员被安排在流程的不同位置，最终为着一个目标共同努力，极大的提高工作效率。

3.4 软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中，这就形成了软件工程过程，简单的说就是开发流程。流程和成功不是等价的，软件流程从策划到实施的思维来定义开发过程，它根据不同的产品特点和以往的成功经验来确定流程。按照流程进行开发可以使得我们减少不必要的错误和隐患，有效的提高产品质量。

3.5 软件质量预测是发现那些模块容易出错，提高软件质量。传统的手工测试很难覆盖软件的全部功能点，手工测试的效率低，并且由于人工操作可变性较大容易造成对测试工作的懈怠，使测试质量降低，软件测试的目的是要发现软件中的错误。通过自动化测试工具的合理使用，可以提高测试的可重复性，缩短测试周期，将核心功能点重点测试，以此来杜绝关键缺陷，降低出现问题后的影响，以免影响到软件整体质量。

3.6 软件的使用者是用户，因此应从用户的角度来不断提高软件质量，软件应满足用户的业务需求，尽可能的与客户沟通获取需求，除了完成需求调研的任务外，同客户有深入的沟通和良好的客户关系也是一个及其有益的收获。既不将质量目标定得太高，根据时间，资源和预算客观情况定义合适的软件质量标准，让用户满意。

3.7 确保从需求获取开始，项目就朝正确的方向迈进，减少总体工作量。尽量在软件开发生命周期的前段时间减少软件缺陷，避免在后期来消灭缺陷，那样耗费的时间和精力更多。让每个人都知道质量的重要性，从心理上更注重代码质量，就会更用心写出高质量的软件。

3.8 对于软件开发来说，要保证软件的质量，需要掌握多方面的技术，包括分析技术、设计技术、编码技术和测试技术等等。参照简明清晰的设计编写代码，容易测试和返工，也更容易诊断和修复缺陷。

优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。

3.9 根据业务需求调整团队和个人的工作目标，并纳入质量考核体系，实施严格的奖惩措施，刺激开发人员的工作效率和工作质量。根据团队成员的执行表现给予适当奖励。

4 结束语

提高软件质量是一项团队运动，整个团队强烈的软件质量意识，是保证软件软件质量的关键，软件质量必须贯穿整个软件的开发生，通过软件初期的质量保证来减少返工次数，不断提高用户满意度，其中作为管理人员要对软件质量进行综合考评，并通过各种手段进行激励团队提高质量，做到软件质量和用户满意度的提高。

参考文献：

[1]刘建辉.提高软件质量的方法研究[D].中国地质大学，2005.

[2]梅宏，王千祥，张路.软件分析技术进展[J].计算机学报，2009（32）.

[3]石柱，何新贵.模糊软件质量综合评价[J].系统工程与电子技术，2002（24）.

质量控制软件 篇7

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

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

软件质量控制的方法主要有目标问题度量法、风险管理法和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.

质量控制软件 篇8

医院卫生装备的质量控制涉及卫生装备的申报、论证、采购、验收、使用、维修、淘汰报废等全寿命质量管理过程,它包括医学计量和卫生装备质量控制两大类。为了实现我院卫生装备质量控制的全程数字化管理,我们对原有采用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.

质量控制软件 篇9

关键词：区域自动气象站,质量控制,装备保障

引言

区域自动气象站的资料质量对气象及相关领域的研究具有很重要的影响, 也是做好公共气象服务的前提[1,2]。近日, 随着闽北松溪县山洪项目单雨量站的安装完毕, 闽北在用的区域自动气象站数量达到了将近300个, 闽北区域自动气象站已经初步形成了一张较为完善的基础观测网络系统, 这对于研究闽北城市局地气候、分析局地小气候规律、做好中小尺度灾害性天气预报, 具有极其重要的作用。如何充分保障和发挥现已建立的这些自动气象站的实际效用并确保资料的代表性和准确性, 最有效的方法就是尽力保证各气象探测设备的正常运行, 因为只有正常工作的自动气象站才能提供持续、可靠的观测资料。

运行监控是保障气象探测设备正常工作的有效手段, 它是通过将远端设备的状态、数据信息等拉到近端, 以便第一时间发现问题、解决问题, 最终达到快速保障的目的。当前, 闽北业务人员监控区域自动气象站的方式主要有以下两种:一是通过省级疑误网站, 该网站每天早晚各弹出一个疑误站点信息供值班人员核实;二是信息中心通过人工监控各个站点的运行情况, 根据报文的传输信息, 结合自己的工程经验做出判断, 进而决定是否需要前往维修。但是这两种方式都有其弊端, 省级疑误网站针对的是全省各地市所有的区域自动气象站, 由于各地市所属的区域自动气象站体现的都是本地气候特征, 因此, 使用统一的判断依据进行质量控制是较为粗糙的, 容易引起误报, 而且该网站只能定时、单一地为各台站提供某个站点某个时次某个要素可疑的信息, 对其判断的依据、可能的故障原因及解决措施等没有作任何说明, 更没有为业务人员提供相关信息的查询功能, 如可疑站点的历史资料、周边的台站资料和历史维修记录等, 这正是业务人员在核实故障时最为需要的信息, 因此实用性不高;对于第二种方式, 由于区域自动气象站具有站点个数多、观测时间间隔短和数据量大等特点, 单一的依靠人工监控区域自动气象站的工作量太大, 可操作性不强。

针对上述问题, 本文采用质量控制的方法, 其主要思路是根据气象学、天气学及气候学原理, 依据《地面气象观测规范》[3]的规定, 进行气象观测数据序列的合理性检验, 同时结合各站的气候背景, 由软件自动对观测资料数据进行检查, 找出不合理、不正常的错误或可疑记录。大量的工程经验证明, 大部分情况下, 错误的观测资料都是由于探测设备出现故障所造成, 因此, 本文设计开发了自动气象站数据实时质量控制软件, 实现了对区域自动气象站的运行监控, 并且根据报文数据特征将远端探测设备的运行情况呈现到近端, 便于业务人员对可疑站点做进一步的核实判断, 也为保障人员快速定位探测设备故障与抢修提供了条件。

1 质量控制系统和流程

质量控制系统的结构如图1所示, 采用了服务器端/客户端混用的架构方式, 其中服务器端运行在市级信息中心, 执行全市区域自动气象站报文的实时质量控制处理, 当监测到可疑信息时, 会立刻对所属台站发出告警信号;客户端部署于各县 (区) 气象台站, 一旦收到告警信号, 立即弹出相应的界面, 业务人员在软件判断的基础上, 结合站点周边的探测环境对判断的结果进行核实, 并将结果直接用于指导装备保障业务。

将质量控制系统分为以下3个模块:

1.1 资料收集及处理

系统定时收集区域自动气象站的报文信息, 采用极值和界限值检查、内部一致性检查、时变一致性检查、公式检查以及空间一致性检查等五种综合检查的方法, 实现了对区域自动气象站实时收集的观测数据 (包括降水、空气温度、风向、风速、本站气压和相对湿度) 的质量控制。针对不同的观测要素, 采用的质量控制方法也不同, 如降水采用气候极值和界限值检查、空间一致性检查以及时间一致性检查, 但是不能用公式检查。

1.2 故障分析及输出

系统融合了丰富的区域自动气象站工程维修经验, 通过对报文数据的特征进行分析和处理, 实现了对区域自动气象站故障的智能判断并提出相应较为常见的解决措施:比如气压观测值为500.4h Pa是气压传感器空载的表现, 此时需重点检查气压传感器与采集器的连接线, 或者考虑更换新的气压传感器;再比如最小湿度100, 相对湿度“///”, 这是湿度传感器高湿的体现, 此时需要对湿度传感器进行调整, 也可以通过万用表测量湿度传感器的电压是否在正常范围内 (0~1V) 。

1.3 人机交互及装备保障

服务器端一旦监测到可疑信息, 立即对所属台站发出告警信息。台站人员在收到告警信息后, 能够直接通过客户度查询可疑站点的相关信息, 包括判断的依据、历史告警信息日志、历史维修记录、周边站点天气现象以及相应的故障解决措施等, 软件界面如图2所示。业务人员在这些信息的基础上, 结合该站周边的探测环境逐一进行核实, 并将核实结果直接用于指导探测设备的保障维护。在保障完成后, 将实地维护信息反馈给服务端, 信息中心根据反馈信息进一步完善质量控制系统。

2 区域自动气象站的质量控制方法

针对自动气象站的质量控制方法, 许多气象工作者都做过大量的研究[4,5,6,7,8,9,10], 这些研究表明, 质量控制最为关键的就是确定判断阈值的范围, 阈值范围如果定的太大, 起不到控制作用, 太小则会将正确数据误判为错误数据, 影响整个质量控制系统的性能。阈值的确定不仅需要考虑当地气候特征, 还需要考虑不同的季节, 才能提高质量控制的准确率。

2.1 极值和界限值检查

气候极值是随地理区域和季节的不同而变化, 各站点的极值参数来源于各站点不同要素项目累年各月的最大值和最小值, 但是由于区域自动气象站建站时间短, 无法形成有效的极值序列, 因此, 区域自动气象站的界限值只能将所属县市级大监站的观测极值作为参考。

本文在闽北近10a大监站的观测数据极值的基础上, 结合区域自动气象站的探测环境, 同时考虑本地有可能出现的特殊天气现象 (如台风等) 对气象要素极值的影响, 设置了各要素的界限范围值:小时降水量, 设定为0~60mm;空气温度, 设定为-12~45℃;风向, 设定为0~360°;风速, 设定为0~40m/s;本站气压, 设定为740~1050h Pa;相对湿度, 设定为0~100%。当观测值超出上述界限范围值, 认为该要素可能有误。

2.2 内部一致性检查

内部一致性检查是利用不同变量间的物理联系, 通过一个变量的观测值, 判断同时刻另一个变量的观测值是否可信。针对同一个时次, 自动气象站采集的各要素值之间必须符合以下关系:

2.2.1 空气温度

对每一次采集的最高温度、空气温度和最低温度进行逻辑判断, 它们之间的关系为最高温度≥空气温度≥最低温度

2.2.2 本站气压

对每一次采集的最高气压、本站气压和最低气压进行判断, 它们之间的关系为最高气压≥本站气压≥最低气压。

2.2.3 相对湿度

对每一次采集的相对湿度和最小湿度进行逻辑判断, 它们之间的关系是相对湿度≥最小湿度。

2.2.4 降水与相对湿度

当前10min存在降水, 其相对湿度必然也较大, 并且根据降水量的大小, 相对湿度的大小也不同, 降水越多越持久, 相对湿度越大, 但是不能超过100%。

2.2.5 降水量与湿度

当前时次的降水量大于前一个时次的降水量, 则当前时次的相对湿度必须减去前一个时次的相对湿度, 否则认为可能有误。

2.3 时变一致性检查

时变一致性检查的目的是为了检验观测值的时间变化率, 剔除不真实的跳跃值。时变一致性检查主要针对降水、空气温度、风速、本站气压和相对湿度等5个要素进行检查, 通过对自动气象站的报文数据与该站前一个时次的要素数据进行逐一对比, 如果在某个要素上, 两个样本的差值超过制定的阈值范围, 则认为该要素数据可能有误, 具体如下:

2.3.1 降水

考虑到闽北夏季强对流天气的现象, 在调研分析近10a的观测数据, 设置降水和风速的时变跳跃的阈值分别为20mm、20m/s, 当前后时刻的差值超过此阈值范围, 则认为可能有误。

2.3.2 空气温度

空气温度的变化受降水、观测时间等因素的影响而不同。具体如下:

2.3.2. 1 白天

空气温度较高, 受降水影响较大。若当前时次存在降水, 则设置空气温度时变跳跃的阈值为T1max;若当前时次没有降水, 则设置空气温度时变跳跃的阈值为T1min, 当前后时次空气温度差值超过此阈值, 则认为可能有误。

2.3.2. 2 夜间

空气温度较低, 受降水影响较小, 若当前时次存在降水, 则设置空气温度时变跳跃值为T2max, 若不存在降水, 则设置空气温度时变跳跃的阈值为T2min, 当前后时刻空气温度差值超过此阈值, 则认为可能有误。

上述4个阈值之间的大小关系为:T1max>T2max>T1min>T2min。

注:白天时间段为8:00~20:00 (不包含20:00) , 夜间为20:00~第2天8:00 (不包含8:00) 。

2.3.3 本站气压

正常情况下, 气压值日变化基本上保持在1~2h Pa (百帕) 范围内, 因此, 设置本站气压时变跳跃的阈值为1h Pa, 且1d内波动范围不能超过5h Pa。当前后时次气压差值超过1h Pa或者1d内气压最大值和最小值之间的差值超过5h Pa, 则认为气压可能有误。

2.3.4 相对湿度

相对湿度的变化受降水、观测时间等因素的影响而不同, 具体如下:

2.3.4. 1 白天

相对湿度较低, 受降水影响较大。若当前时次存在降水, 则允许相对湿度的时变跳跃的阈值为RH1max, 若不存在降水, 则设置为RH1min, 超过这个阈值, 则认为可能有误。

2.3.4. 2 夜间

相对湿度较高, 受降水影响与白天相比略低, 如果当前时次存在降水, 则允许的相对湿度时变跳跃的阈值设置为RH2max, 否则为RH2min, 超过这个阈值, 则认为可能有误。

上述4个阈值之间的大小关系为:RH1max>RH2max>RH1min>RH2min。

2.4 公式检查

鞠晓慧等[11]对气压值与海拔高度的关系做过较为深入的研究, 本文采用的是地面气象观测规范中所使用的公式[3]:

式中P0——海平面气压;

Ph——本站气压;

h——气压传感器海拔高度;

tm——气柱平均温度。

其中计算气柱平均温度tm公式:

式中tm——观测时的气温;

t12——观测前12h的气温;

h——气压传感器的海拔高度。

将公式所得理论气压值与本站实测气压值进行比较, 如果差值较大, 则认为该要素可能有误。从闽北近10a的气压数据中发现, 同一个台站的气压值1a的波动范围在50~55h Pa, 因此, 算法中设置实测值与理论值之间的差值的允许范围的阈值为30h Pa, 当超过这个范围时, 则认为气压值可能有误。

2.5 空间一致性检查

空间一致性是依据气象参数具有一定的空间分布特点而进行的检查, 其有效性取决于区域自动气象站网的密度和被检查要素与空间的相关程度。在自动气象站各要素中, 降水、空气温度、湿度和气压与空间分布关系较为密切, 通过观察发现, 上述4种要素在20km内具有较大的相关性。

检查方法一般有以下两种方式:一是利用与被检查站点相邻近的站点同时观测的气象要素值进行比较, 二是利用邻近站点的观测值通过一定的插值方法计算出被检查站点的估计值, 然后对观测值进行与估计值进行比较[1]。本文使用第一种方法, 通过与周边的自动气象站站点的各要素信息逐一对比, 如果周边站点的要素都与该站点的要素差距较大, 则认为该站点的这项要素有误, 具体如下:邻站规划为以该自动气象站点为中心, 向外立体扫描20km以内的所有自动气象站站点, 将其添加到自己的邻站列表;当邻站数量达到3个或以上时, 执行空间一致性算法;计算邻站海拔高度与本站的海拔高度的差值;根据海拔高度差值的不同, 设定各要素不同的阈值, 海拔高度差值越大, 允许的阈值范围也越大, 反之亦然;此外, 当邻站出现缺报或存在某个要素数据缺测时, 将该站从邻站列表中删除, 当邻站个数小于3时, 该自动气象站停止空间一致性算法检查。

2.6 算法小结

对上述各要素所采用的质量控制方法进行归类总结, 如表1所示。

注:“▲”表示采用该方法。

3 软件测试与性能分析

应用上述算法开发软件, 对福建省南平市153个区域自动气象站进行实时质量控制, 测试时间从2013年1~8月, 监测到可疑站点数52个, 发生故障次数为80次, 发出可疑站点信息3278条 (整点报文) , 平均每次故障发出41条可疑信息, 即从发生故障到排除故障平均只需41h, 具体各要素的故障信息如表2所示, 其中可疑信息条数指软件判断发出的可疑信息条数, 可疑站点数指软件判断发生故障的站点数, 人工核实站点数指经过人机交互后核实的故障站点数, 保障核实站点数为经过装备保障维护后确实发生故障的站点数。

从表2中可以看出, 软件判断的结果与人工核实的结果略有出入, 但人工核实站点数与保障核实站点数几乎完全一样, 前者是由于受极端天气影响以及定期维护自动气象站时不小心所造成, 如受2013年7月13日苏利台风影响, 南平南部部分站点气压突然降低引起误判。但是经过人工核实后, 软件误判的情况得到了有效地控制, 基本上消除了误判现象, 大幅提高了故障判断的准确率。

测试结果表明, 本文所开发的自动气象站实时质量控制处理软件能够准确、快速地发现并定位区域自动气象站的故障信息, 确实有效地提高了闽北装备保障的业务水平和区域内自动气象站正常工作的比例, 大大提高了区域自动气象站观测资料的质量及可用性。

4 结语

将装备保障与质量控制建立在同一条业务线, 通过质量控制促进提升装备保障的维护效率, 反过来, 装备保障的及时到位又能够促进提高区域自动气象站观测资料的质量及可用性, 两者相辅相成, 相互促进。

区域自动气象站的质量控制应以软件监控为主、人工核实为辅, 首先依靠软件监控进行第一级质量控制, 实现从海量数据中获取可疑站点信息, 再依靠人工对第一级质量控制处理后的结果进行核实, 即为第二级质量控制。

针对未来开发省级、国家级的质量控制系统, 必须考虑各个地区不同的气候特征, 单独为不同地市在不同季节, 尤其是气候特征明显存在差异的地区单独设定不同的标准阈值, 才能提高质量控制的准确率与装备保障的维护效率。

参考文献

[1]何健, 王潜梅, 钱光明, 等.广东省区域自动气象站资料的质量控制与评估[J].广东气象, 2011, 33 (03) :37-40.

[2]李志鹏, 张玮, 黄少平, 等.自动气象站数据实时质量控制业务软件设计与实现[J].气象, 2012, 38 (03) :371-376.

[3]中国气象局.地面气象观测规范[M].北京:气象出版社, 2003:9-34.

[4]陶士伟, 仲跻芹, 徐枝芳, 等.地面自动站资料质量控制方案及应用[J].高原气象, 2009, 28 (05) :1201-1210.

[5]王海军, 杨志彪, 杨代才, 等.自动气象站实时资料自动质量控制方法及其应用[J].气象, 2007, 33 (10) :102-109.

[6]窦以文, 屈玉贵, 陶士伟, 等.北京自动气象站实时数据质量控制应用[J].气象, 2008, 34 (08) :77-81.

[7]任芝花, 熊安元.地面自动站观测资料三级质量控制业务系统的研制[J].气象, 2007, 33 (01) :19-24.

[8]王建庄, 许沛林, 彭慧英, 等.Ⅱ型自动气象站数据采集的实时质量控制[J].广东气象, 2009, 31 (05) :57-58

[9]王新华, 罗四维, 刘小宁, 等.国家级地面自动站A文件质量控制方法及软件开发[J].气象, 2006, 32 (03) :107-112.

[10]杨晓武, 黄兴友, 徐平.加密自动气象站实时监控与查询显示系统[J].气象科技, 2008, 36 (04) :506-509.

质量控制软件 篇10

高校计算机公共课程实验教学改革是本科教学改革的重点内容之一,是学生创新能力培养的关键。但目前实验课程教学改革主要是从制度、体系和教学手段开展的。主要提出的思路和方法如:采用多媒体授课,利用网络平台进行网络化教学,开放机房,实现开放式教学,让学生自由支配学习时间。这存在以下不足:(1)学生的实际动手能力参差不齐,很难保证绝大多数学生都能有效完成。(2)学生兴趣问题。目前全国高校的非计算机专业的几乎都开设了计算机公共课程,如何激发诸如文科和艺术类等专业学生的学习兴趣,帮助他们完成这些实验,是实验教学改革必须考虑的问题。(3)师资、配套设施和学生人数的矛盾。由于高校扩招,师资和配套设施的建设往往跟不上学生扩招的规模。(4)课时和考核的办法。现在的学生面临很大的学习压力,要想在极有限的时间内学会和掌握一定的计算机操作技能,并能完成设计性实验和创新性实验,对课时和教学内容组织都是严峻的挑战。(5)如何实现计算机智能自动辅导,实验过程自动适应和有效控制等,都是必须要考虑的。

本实验质量控制系统就是针对这些问题提出的。

2 系统设计

2.1 系统功能设计

实验质量控制系统是一个关于开放性自适用的实验辅助系统的总体结构,目的是针对计算机实验教学提供管理、辅助、自动分析和适用的功能,主要有几个方面:(1)管理和编辑实验内容,由教师或学生根据教学大纲编辑制定实验计划;(2)对实验过程进行引导、管理、自动记录和自动分析;(3)在教学过程进行干预和辅助,引入教学反馈和效果追踪;(4)实验过程重放功能,确保实验的完成和可重放,便于分析和改进实验过程;(5)实验全程管理,包括考勤、内容安排与组织,实验评价等。整个系统除虚拟学生社区采用Browser/Server结构以保证开放性和远程操作的简便性以外,其他部分均采用Client/Server模式以保证强大灵活的管理功能、快速的响应时间和并发响应能力。系统主要功能模块如图1所示,其中:

1)实验设计与编辑模块:主要实现实验素材的组织和编辑,以及“三性”实验的设计,通过实验设计环节,可以让学生明确实验的思路和目的,预计实验输出,让学生对整个实验有更全面和准确的理解,有效预防“三性”实验过程中经常出现的实验目的不明确、实验过程混乱、对结果没有正确预计、实验数据收集不及时不全面等问题,有效提高实验的成功率。

2)实验课堂管理:教师通过实验课堂管理来计划、开设、监测、控制、评价、回顾和分析实验课程,并由系统自动完成师生出勤情况统计、自动向缺课、迟到、早退的学生发送提示邮件,查看当前实验状态,监控学生屏幕,获取学生操作的文件、数据和内存状态等信息。控制学生能否获得系统提示和辅导,授权学生运行特定的程序或访问特定的网站,查阅学生电子实验报告和实验得分,并允许教师随时干预以上过程。

3)学生实验平台:通过这个平台,学生可了解实验目的、内容、难点重点、注意事项,相关教学视频,在系统的引导下完成实验过程的每个步骤,并填写各步骤的实验结果,在教师的授权下,可以根据所做的情况获得实时的实验帮助和提示,此外,系统还在后台自动记录学生实验过程,包括按指定的时间间隔抓取实验屏幕,提交内存数据、保存原始数据,自动记录学生的所有键盘和鼠标操作等信息,如在什么时候运行了什么程序,访问了什么网址,输入了什么,并可以发起和教师的远程协助、电子举手和对话。

4)虚拟学习社区:学生可以在这个平台上获取各种教学资源,如下载教师课件和各类补充资料,发起讨论组,反馈学习意见等,获得自己的学习曲线、学习进度的相关统计数据,系统自动生成学习建议和分析报告。教师则可以在平台上发布信息,给学生的PUSH相关学习资料,查看全班或特定同学的学习曲线与统计数据,及系统推荐意见。

5)实验教学管理和监控平台:教学领导可以通过这个平台获得远程的实验进行情况,所有教师和学生的考勤情况,教学效果报告和统计数据等。

6)智能分析系统:该模块主要是根据相关教学理论,综合运用了数据挖掘、人工智能、自动适应等智能分析技术,充分发掘学生实验操作学习的认知规律和学习模式,针对单个学生的特点和习惯,自动管理其学习进度,根据当前所学内容,产生教与学的建议,生成各类统计报表提交给教师和教学主管。

2.2 平台和开发工具选择

在综合考虑运行效率、开发效率、现有技术资源、用户群和发展趋势、安装发行配置等因素后,课题组选择了Microsoft Windows 2000/2003 Server作为服务器操作系统,数据库软件使用Microsoft SQL Server2000,兼容SQL Server 2005。在考虑到发行后文件大小,运行速度、软硬件要求和发行配置等因素后,C/S前端开发工具选择了Microsoft Visual C++6.0,它开发的程序运行速度快,文件小,发行时不要求.Net Framework,是理想的前端开发工具。实验课堂管理端由于安装数量少,教师机配置一般较好,需要报表较多等原因,使用Microsoft Visual C#开发,虚拟学习社区则采用主流的JSP开发,对客户端几乎没有要求。数据建模工具选择了Power Designer而不是Rational Rose,因为:(1)Rose倾向大而全,没有将数据库设计和面向对象设计清晰地分开,而Power Designer则比较精细和具体化,将两者划分到独立的模型文件中,并通过模型之间的转换工具建立各模型的关联。(2)Rose在逆向工程,文档输出,代码生成等输入输出功能上表现的比较生硬单调,而Power Designer在逆向工程,尤其是文档输出和代码生成这些功能上提供了精细的控制,让用户拥有高度的自由。(3)操作习惯上,Rose更多偏向于鼠标操作,对键盘支持不及Power Designer。(4)Rose对数据模型的支持相对粗糙,内嵌只支持Oracle,对象模型主要支持Java,VC和VB三种语言;而Power Designer支持20余种数据库的数据模型和11种主流语言。(5)Rose耗资源多,容易发生异常操作。

2.3 数据库和界面设计

实际应用中,需要涉及到很多方面的信息,以学生实验平台涉及到的部分数据模型为例,包括:学生(学号#,姓名,性别,专业,院系,年级,出生年月,联系方式…),实验信息(实验编号#,实验名,实验目的,实验重点,实验难点,实验准备,实验类型,实验内容,实验注意事项,实验讲解视频链接…),实验步骤信息(实验步骤编号#,实验编号#,实验步骤名,实验步骤要求,实验步骤素材,该步骤评分函数或程序名,该步骤评分参数1…,步骤提示,步骤帮助类型,帮助文本,帮助视频…,该步骤记分权重…),此外还有实验课堂开设的情况,学生的登录情况,每个实验的完成情况,每个实验步骤的完成情况,每个步骤的原始数据等,学生的所有键盘输入,鼠标输入,应用程序操作等。由于数据量十分庞大,需要在设计的时候,充分考虑应用的特点,优化数据库的设计,保证查询速度。如通过优化或编写存储过程,避免将所有数据读取到客户端再进行筛选等操作,以提高数据访问速度。同时还要尽量减少数据库读取操作,通过压缩原始数据等方法来减少数据传输。经实际运行检验,在并发800-1000客户访问时,系统十分流畅,运行非常稳定。

界面设计则充分考虑了软件工程的相关理论和学生们普遍熟悉腾讯QQ和MSN等即时通讯软件的现状,一定程度借鉴和模仿这两款软件,以便于学生不需要专门学习就能熟练使用。通过禁止或隐藏不相关界面元素避免对学生操作产生干扰。并智能判断学生可能的操作行为,以动画或闪烁界面元素的方式来提醒其可能的操作行为。程序部分界面截图如图2,图3,图4等。

3 系统创新点

目前市面上尚无类似产品。因此系统开发成功,具有较重要的意义。其主要创新点在:(1)以培养学生能力为中心:注重创新能力、自主学习等方面能力的培养。(2)遵循高等教育教学的内在规律:用先进的教学管理理念与方法,借鉴ISO质量管理思想,构建多维实验教学质量监控体系。(3)基于任务驱动。(4)基于过程控制:借鉴了ISO质量控制体系的“过程控制”思想。(5)各类报表自动生成:包括统计、分析和管理的各类报表,并可自由转换成其他格式。(6)实现了实验过程的“七可”:即实验过程可引导、可记录、可监督,可干预,可统计,可设计,可管理。(7)适用性强:实验难易度可控制,完成情况可统计。教师和学生可调整实验的内容和步骤及设计实验。(8)实验过程和结果可保存,实验过程可重现:学生实验过程中的所有原始数据,素材,原程序,设备属性(计算机名,软硬件配置,实验时屏幕状态,内存和输出等)均可记录,必要时可重现全部实验过程。此外,系统还丰富了开放教学的内容,一定程度缓解了高校扩招后师生比失衡的问题,有效地保证“三性”实验的开展。

4 结束语

目前,本系统已在湖南师范大学的计算机公共基础课程教学中得到了广泛的应用,深受师生好评,并得到了本科教学评估专家们肯定。随着教学的发展和需要,一套设计优良的实验质量控制系统肯定是大受欢迎的。但开发这样一个系统,不是一蹴而就的,还需要考虑很多方面,还需要以后不断完善和补充。

摘要：针对当前计算机公共课程实验教学中存在的问题,综合C/S和B/S软件结构的优点,开发了一套实验教学质量控制软件,包括实验设计和编辑、实验课堂管理、学生操作平台、教学领导监管平台和虚拟学习摄取几大功能模块。基于数据挖掘和人工智能技术,自动适应学生的学习过程,对教和学提供智能建议。系统的实现,从技术角度保证了计算机实验教学质量控制的实现。研究成果在湖南省教改课题中得到了很好的应用。

关键词：计算机公共课程,实验教学质量,智能分析

参考文献

[1]国务院.中共中央、国务院关于深化教育改革,全面推进素质教育的决定[P].1999.6.13at http://www.cycnet.com/zuzhi/ywdd/files/014.htm.visited.2007.5.10

[2]蒋少华.高校计算机基础实验教学质量控制系统研究与实现[Z].2006年湖南省普通高等学校教学改革研究项目申请书.2006.5

网络控制软件设计与实施 篇11

摘要:文章就大部分企业局域网络遇到的网络速度慢、影响企业正常业务运行、又难以管理的网络问题,以客户端控制进程并与服务器端进行通讯方式编写了网络控制软件。该软件实际应用中采用了“白名单”思路控制客户端的软件操作,而且能够根据时间进行控制,从而达到管理网络终端,防止网络带宽被占用,提高网络速度的目的。

关键词:网络 终端进程 控制

0 引言

随着计算机网络的发展和普及,各大企业都建立了自己的局域网。利用网络不单纯是上网浏览网页、收发电子邮件,更主要的是业务在网上的传递,如:财务系统、物资系统、人力资源等系统的应用。这些系统的应用,对企业网络速度、网络的稳定性和网络安全性有了严格的要求。目前,几乎所有的企业内部网络都遇到了网络速度慢,影响业务的正常运行,即便是主干千兆、桌面百兆的网络、互联网出口20兆的网络。经过我们调查分析,其实真正影响网络速度是下载软件、大型游戏等软件的运行以及病毒木马的传播。网络终端控制软件就是针对企业面临的这种情况,通过技术手段对影响网络速度的软件、游戏加以控制,来保证企业正常业务的运行。该软件采用控制进程的方法,对非法进程和不允许运行的进程进行控制,同时该软件对木马软件也起到一定的防范作用。

1 特点

网络终端控制软件与网络管理软件对比

网管软件的主要协议

虽然各网管软件提供商在产品性能方面不尽相同,但是基本上都采用了SNMP、DMI、WMI、TCP/IP、SPX/IPX、SNA、DECNET、SAN等协议,如3Com Network、BMC software、SiteView等。SNMP是由一系列协议组和规范组成的,它们提供了一种从网络上的设备中收集网络管理信息的方法。另外,有些网络管理软件采用了CMIP协议(一种较SNMP更为详细的网络管理协议)但由于其自身的一些缺陷,并未被广泛使用。

1.1 网管软件的主要技术 随着网络管理需求的不断增加,越来越多的网络管理技术被开发和使用,下面简要介绍网络管理领域相关的一些主要技术。

1.1.1 Portal技术 Portal 是一个基于浏览器的、建立和开发企业信息门户的软件环境,具有很强的可扩展性、兼容性和综合性。它提供了对分布式软件服务和信息资源的安全、可管理的框架。便于使用的Portal界面为每个用户提供了他所需要的信息和Web内容,同时也保证了每个用户只能访问他所能访问的信息资源和应用逻辑。

1.1.2 RMON技术 网络管理技术的一个新的趋势是使用RMON(远程网络监控)。RMON的目标是为了扩展SNMP的MIB-II(管理信息库),使SNMP更为有效、更为积极主动地监控远程设备。

1.1.3 基于Web的网络管理技术 由于Web有独立的平台,且易于控制和使用,因而常被用来实现可视化的显示。

1.1.4 XML技术 采用XML技术,系统提供了标准的信息源,可以与企业内部的其它专业系统或外部系统进行数据交互。

1.1.5 CORBA技术 CORBA是OMG(Object Management Group)为解决不同软硬件产品之间互操作而提出的一种解决方案。简单地说,CORBA是一个面向对象的分布式计算平台,它允许不同的程序之间可以透明地进行互操作,而不用关心对方位于何地、由谁来设计、运行于何种软硬件平台以及用何种语言实现等,从而使不同的网络管理模式能够结合在一起。

SNMP是简单网络管理协议(Simple Network Management Protocol)的缩写,它是由Internet工程任务组织(Internet Engineering Task Force)的研究小组为了解决Internet上的路由器管理问题而提出的,提供了一种从网络上的设备中收集网络管理信息的方法,也为设备向网络管理中心报告问题和错误提供了一种方法。

具有远程管理能力的SNMP使管理人员可以对整个子网进行管理,而不是对整个子网内的设备进行管理。SNMP是一个标准的用于管理IP网络上结点的协议。此协议包括了监视和控制变量集以及用于监视设备的两个数据格式:SMI和MIB。

目前大部分网络管理软件采用SNMP协议进行网络管理,与网络控制软件相比

1.2 网络终端控制软件 优点:①可以查看被管理终端的进程、任务,便于终端问题的维护(木马、非法进程等)。②不进行网络数据过滤,所以不降低网络速度。③可以群发消息。④可以远程设置终端,对终端进行控制。⑤不用增加服务器等其他硬件。⑥不用改变网络架构。缺点:①安装麻烦,工作量大(需要逐个终端安装)。②需要制定相应的管理制度,防止程序删除,不受服务器端控制。

2 结构及功能

2.1 软件分为服务器端和客户端,采用TCP/IP协议进行通讯。

2.1.1 服务器端:管理防火墙等硬件设备;更新控制程序;查询客户端控制情况。采用了在服务器端控制防火墙的方法,解决安装客户端的麻烦。即受控计算机不安装客户端,将不能上互联网。同时软件采用了反向思维方法,不允许运行即为禁止,减少了系统管理员每发现一个要禁止的软件,就要维护一次的繁琐工作量(采用了白名单的管理方式)。

2.1.2 客户端:接收服务器端指令;控制客户端进程;观测客户端网络连接、任务、流量等信息。

2.2 软件功能:控制局域网内计算机终端的软件运行;远程设置控制信息(单一计算机、所有在线计算机);可以分时段进行控制(上班时间禁止、下班时间允许等);计算机终端日志统计;查看网络端口;查看控制列表;查看进程列表;查看任务列表等;被控制的计算机IP和MAC地址绑定进行客户端控制;从技术上可以监测到客户端的任何活动。

3 关键技术

3.1 进程控制 进程管理在Windows中是一个比较重要的内容,由于每一个正在运行的程序(包括Windows的后台程序和动态链接库)都对应有各自的进程,通过对进程的管理可以防止一些非法程序(如特洛伊木马程序)的运行,但是Windows的任务管理器虽然能够中止进程,不过它的进程列表里面已经屏蔽了某些与系统有关的进程,现在有的特洛伊木马(如冰河)在编程时将自己注册为系统服务,因此通过Windows的任务管理器并不能中止它的进程;而Windows的系统信息工具msinfo32.exe虽然能够列出系统中所有的进程,但是并不能中止进程,所以也是于事无补。

为此我们可以自己编写一个进程管理软件,首先,它要能够列出系统中的所有进程,其次也要能够中止系统中任意一个进程(当然有些进程中止后将有可能导致死机)。

编程思路:列出系统进程一般的方法是通过调用一组ToolHelp32函数,该组函数存在于kernel32.dll链接库中,它有许多功能,而枚举系统中的进程只是它众多功能中的一项。下面是要用到的几个关于进程的API函数:CreateToolHelpSnapshot()、ProcessFirst()、ProcessNext()。不知道是什么原因,这么重要的函数微软居然并没有将其录入到VB的API文本浏览器中,因此我们只好手工将其录入了,下面是声明:

Public Declare Function CreateToolhelpSnapshot Lib "kernel32" Alias "CreateToolhelp32Snapshot" (ByVal lFlags As Long,ByVal lProcessID As Long) As Long

Public Declare Function ProcessFirst Lib "kernel32" Alias "Process32First" (ByVal hSnapShot As Long,uProcess As PROCESSENTRY32) As Long

Public Declare Function ProcessNext Lib "kernel32" Alias "Process32Next" (ByVal hSnapShot As Long,uProcess As PROCESSENTRY32) As Long

此外还需要定义一个PROCESSENTRY32结构,这个结构中包含有有关系统中进程的某些信息。

Public Type PROCESSENTRY32

dwSize As Long

cntUsage As Long

th32ProcessID As Long

th32DefaultHeapID As Long

th32ModuleID As Long

cntThreads As Long

th32ParentProcessID As Long

pcPriClassBase As Long

dwFlags As Long

szExeFile As String*MAX_PATH

End Type

下面是列出系统进程的步骤:

3.1.1 用CreateToolHelpSnapshot()函数来创建系统中进程信息的“快照”,该函数返回一个句柄(该句柄将在下面的函数中得到应用)。

3.1.2 用ProcessFirst()函数从以上“快照”中获取进程,该函数有两个参数,第一个是第一步中函数返回的句柄,第二个是指向PROCESSENTRY32结构的指针,当系统中还有其它进程时,该函数返回true。

3.1.3 用ProcessNext()函数从“快照”中不断获取进程,直到它返回false为止;关闭进程也是一个值得讨论的问题,传统的方法是用GetWindow来查找窗口句柄,再利用GetWindowText来获得窗口的标题,然后利用SendMessage函数发送WM_CLOSE消息来关闭该程序。不过这种方法有很大的缺陷:首先是有的窗口是没有标题栏的,这样的程序是无法通过该方法关闭的;其次,这种方法对动态链接库也是无法关闭的。在这里我们可以充分利用PROCESSENTRY32结构,它里面有一个th32ProcessID成员,通过TerminateProcess()函数就可以关闭进程。

3.2 设计思路:为了减少网络管理者的工作量,程序采用反向思维方式,即非允许的即时被控制的(白名单)。软件提供允许进程列表,系统随时查询运行进程,对照控制列表实现对客户的进程的控制。

软件开包括任务控制、流量控制、网络连接等技术,由于篇幅有限笔者不再赘述。

4 实施与应用

软件使用 客户端软件安装运行后不用操作,整个操作全部在服务器端。

服务器管理软件界面如下:

4.1 远程设置某一计算机允许或禁止某一软件运行

例如设置1#计算机禁止“任务管理器”运行,鼠标单击计算机列表中要设置的计算机,选择软件名称“任务管理器”,点击禁止运行,点击“远程设置”即可。

注意:安装完成客户端以后,控制列表中没有允许的都将不能使用,系统管理员需要提前作调查(如:CAD、工资软件、Windows 媒体播放器、PDF阅读器等等)是否允许运行,以免造成这些软件不能运行,影响正常工作。

默认的计算机控制列表如下:

ALG.EXE [全天] [允许]

BT下载 [全天] [禁止]

CSRSS.EXE [全天] [允许]

CTFMON.EXE [全天] [允许]

CTFON.EXE [全天] [允许]

EXCEL.EXE [全天] [允许]

EXPLORER.EXE [全天] [允许]

Foxmail.exe [全天] [允许]

……………

大唐豪侠 [上班] [禁止]

大唐豪侠设置 [上班] [禁止]

记事本 [全天] [允许]

金山词霸 [全天] [允许]

任务管理器 [全天] [允许]

瑞星杀毒RavMonD [全天] [允许]

瑞星杀毒软件Rav [全天] [允许]

瑞星杀毒软件RavStub [全天] [允许]

纸牌游戏 [上班] [禁止]

4.2 查看进程、任务、端口等信息 选择要查看的计算机,点击相应的按钮即可。查看后的列表信息可以复制到记事本等文字处理软件保存。

4.3 控制设置(修改控制软件) 点击“控制设置”按纽后进入设置界面,如下图

5 防火墙控制

服务器端与防火墙连接,对于受控计算机,不在线时,防火墙自动添加命令,不让其访问互联网。设置方法如下:

填写被控制的计算机IP和MAC地址

注意:该表将与防火墙中阻止主机数据同步,不要删除表中内容。不要在自动控制时填写此表。

单击“主机阻止”按钮,出现以下界面:

选择“连接”菜单,中的设置,选择串口,确保该串口已经联通了防火墙。选择“连接”。输入用户名、密码,单击登录,测试能否登陆成功。

登陆成功后,单击“自动控制”,全部设置完毕。

6 结论

该软件实际应用中能够控制客户端的软件操作,甚至其他软件的安装也可以被控制,现有的软件如果不设置在“白名单”(允许)中也不能运行。而且能够根据时间进行控制,在实际运行中由于控制相对严格,同时因为安装在客户端,用户担心有隐私被发现,用户存在不愿意接受的情况。还需要制定相应的管理制度来制约,采用技术加管理的方式控制终端程序的运行,从而达到管理防止网络带宽被占用的目的。被管理的计算机被强行安装控制软件,未安装控制软件的计算机不运行上网。系统管理员注意收集被控制软件的信息,经常更新控制库。根据用户需求,下一步需要增加一些终端资产管理的功能(计算机台账)。

参考文献:

[1]林永.Widnows API编程手册.人民邮电出版社.2002-06-24.

[2]http://www.snmpc.com.cn/news/readnews2.asp?NewsID=187.

[3]http://vb.xin-soft.com/resource/article/OCX/71.txt.

计算机软件质量和软件质量保证 篇12

软件质量在软件开发中占有重要的地位, 在软件开发的各个阶段必须给予高度的重视, 否则会影响软件的使用。软件质量的度量可以采用相关的技术模型, 通过具体的指标得以反映。软件的复杂性与软件的质量有密切的关系。结构简单的软件, 对于保证软件的质量有很大的帮助作用, 所以在进行软件设计时, 应当尽量保证设计简单的软件结构。软件的可靠性是软件质量的反映。从某种意义上说, 软件的可靠性高说明软件的质量高, 软件的可靠性可以通过有关指标和模型反映出来。在软件开发中, 要保证软件的质量, 因此应当尽量避免软件错误, 其中, 有些避免不了的错误应当采用软件容错的技术进行解决。

2 软件质量问题分析

软件不同于硬件, 软件不会用坏, 不存在零件更换问题, 但不允许存在误差, 不能发生错误, 否则后果十分严重。医疗系统中的软件错误可能造成生命危险, 银行系统中的软件错误会使金融混乱, 航空管理系统中的错误会造成飞机失事。例如, 美国在一次发射火箭的实验中, 由于飞行计划程序里漏掉一个连字符而导致了火箭实验的失败。任何企业都需要有效的管理方法, 软件企业需要的管理方法又与其他类型的企业不同。

在国内软件企业管理的经验比较少, 人员也比较缺乏, 没有形成一个有效的体系。国际上流行的软件过程的认证方法 (如, IS09000和SW-CMM) 在国内虽然已引起足够的认识, 但通过认证的情况并不理想。在这种情况下, 软件企业承担大型软件工程和系统设计、开发、集成能力相对较弱, 并造成在国际市场上处于不利的竞争地位。当前, 软件质量问题比较多, 其主要原因是软件企业管理水平跟不上。

3 影响软件质量的因素

软件的正确性、可靠性和安全性是影响软件质量的三个重要因素。根据Mc Call等人提出的软件质量度量模型, 正确性是指程序满足其规格说明和完成用户任务目标的程度。正确性的评价准则包括:可跟踪性、完整性和一致性;可靠性是指程序在要求的精度下, 能够完成其规定功能的期望程度。可靠性的评价准则包括:容错性、准确性、一致性、模块性和简洁性;安全性则是对软件的完备性进行评价的准则之一, 指控制或保护程序和数据机制的有效性, 比如对于合理的输入, 系统会给出正确的结果, 而对于不合理的输入程序则予以拒绝等。在1985年ISO建议的软件质量度量模型中, 正确性和安全性是软件质量需求评价准则 (SQRC) 中的两条准则, 前者包括软件质量设计评价难则 (SQDC) 中的可跟踪性、完备性和一致性, 后者则包括其中的存取控制和存取审查。而Mc Call模型中的可靠性因素则体现在可容性准则和可维护性准则中。其他的影响软件质量的主要因素有:

1) 可测试性:程序容易测试的程度。

2) 适应性:修正和改进系统所需要的工作量的大小。

3) 可维修性:诊断和改正系统错误所需要的工作量大小。

4) 效率:为了完成预定的任务, 系统耗费资源的程度。

5) 可理解性:理解和使用该系统的容易程度。

6) 可用性:系统在完成预定功能时令人满意的程度。

7) 风险性:按预定的成本和进度开发出系统, 并为用户所满意的程度。

4 改进软件质量保证的技术

4.1 软件复用技术

由于封装和继承的特性, 面向对象方法比其他软件开发方法更适于支持软件复用。封装意味着可以将表示构件的类看做黑盒子。用户只需了解类的外部接口, 即了解它能够响应哪些消息, 相应的对象行为是什么。继承是指在定义新的子类时, 可利用可复用构件库中已有的父类的属性和操作。当然, 子类也可以修改父类的属性与操作, 或者引进新的属性与操作。构件的用户不需要了解构件的实现细节。

4.2 容错技术

所谓“容错”, 就是在出现有限数目的硬件或软件故障的情况下, 系统仍可提供连续正确执行的内在能力。容错和避错是不同的, 容错主要是针对版本中的故障向系统提供保护。组成容错软件的每一个版本的程序设计也要求尽量采用避错技术, 防止单版本领繁出错。但在容错系统的单版本设计时, 避错技术的应用要考虑成本分配上的合理性, 以使总体上符合效益成本比最大的要求。软件容错的目的是屏蔽软件故障, 恢复因出错而影响的运行进程。尽管对于整个这类系统来说, 由于硬件 (包括软件载体) 瞬时干扰引起的故障也能起到一定的屏蔽作用, 但它和专门设计的、以软件为手段实现硬件容错的系统是不同的。软件容错的实现需要硬件的保证和协同。如果软件容错配合以合理的硬件冗余, 可以起到比各自单独考虑容错更好的作用。

4.3 软件工程标准化

在开发一个软件时, 需要有多层次、不同分工的人员相互配合;在开发项目的各个部分以及各开发阶段之间, 也都存在着许多联系和衔接。把这些错综复杂的关系协调好, 需要有一系列统一的约束和规定。在软件开发项目取得阶段成果或最后完成时, 还需要进行阶段评审和验收测试。投入运行的软件, 其维护工作中遇到的问题又与开发工作有着密切的关系。软件的管理工作则渗透到软件生存期的每个环节。所有这些都要求提供统一的行为规范和衡量准则, 使得各种工作能有章可循。

4.4 软件过程评估与改进

软件过程是软件生存期中的一系列相关的过程, 又称为软件生存期过程。过程是活动的集合, 活动是任务的集合。任务是将输入变换为输出的操作。活动的执行可以是顺序的、重复的、并行的、嵌套的。软件过程的考虑主要针对软件生产和管理。为了得到满足要求的软件产品, 不但需要有好的开发方法, 还需要有好的工程支持和工程管理。就是说, 软件过程不仅要有工程观点, 还应有系统观点、管理观点、运行观点和用户观点。

软件质量保证和全面质量管理的思想是一致的, 都指出了不应该只在一个环节上, 比如测试环节来保证软件质量, 我们需要建立众多的辅助流程, 全面地去改进、控制软件流程来保证软件质量。

参考文献

[1]李康荣.Web软件质量层次分析评价方法研究[J].微计算机信息, 2010 (3) :25-26.

[2]宋志秋, 钱英军.基于CMM的软件过程方法研究[J].经济研究导刊, 2010 (1) :251-252.

[3]张旭, 王鹏, 习媛媛, 等.单元测试在软件质量保证中的应用研究[J].煤炭技术, 2010 (6) :185-186.

[4]陈周天.浅谈软件的可靠性[J].黑龙江科技信息, 2010 (10) :65-66.

[5]邢小英.基于软件Agent技术的软件质量保证研究[J].宁波工程学院学报, 2010 (2) :59-62.

[6]吴晓姝.浅谈软件开发过程中的软件质量保证[J].电大理工, 2010 (1) :48-50.