如何实施软件质量保证

如何实施软件质量保证


软件质量保证(即SQA——Software Quality Assurance),是CMM2级中的一个关键过程域,它是贯穿整个软件过程的第三方独立审查活动,出现在大多数关键过程域的检查与验证的公共特性中,在整个软件开发过程中充当重要角色。

从CMM2级中包含的6个关键过程域来看,无论是需求管理、软件项目计划、软件项目跟踪与监控,还是软件子合同管理、软件配置管理,都不同程度地存在于我们现在正在进行的软件项目开发过程中,对于它们的了解我们已经不再陌生,只有SQA这个关键过程域,是在我们准备以CMM2级要求的关键过程域为基础进行软件过程改进前未接触过的。

在很多软件企业中还没有与之相对应的人员和工作方法,整套关注软件开发过程的软件质量保证体系还没有建立起来。所以,在企业以CMM2级关键过程域为参考进行软件过程改进时,SQA往往是一个难点,直接涉及到组织结构的变化。

实施SQA的目的

软件质量保证的目标是以独立审查方式,从第三方的角度监控软件开发任务的执行,就软件项目是否正遵循已制定的计划、标准和规程给开发人员和管理层提供反映产品和过程质量的信息和数据,提高项目透明度,同时辅助软件工程组取得高质量的软件产品。主要包括以下四个方面:

● 通过监控软件开发过程来保证产品质量;

● 保证开发出来的软件和软件开发过程符合相应标准与规程;

● 保证软件产品、软件过程中存在的不符合问题得到处理,必要时将问题反映给高级管理者;

● 确保项目组制定的计划、标准和规程适合项目组需要,同时满足评审和审计需要;

除了以上四点之外,我们还希望SQA能作为软件工程过程小组(SEPG)在项目组中的延伸,能够收集项目中好的实施方法和发现实施不利的原因,为修改企业内部软件开发整体规范提供依据,为其他项目组的开发过程实施提供先进方法和样例。

对SQA人员的素质要求

1. SQA人员(有时简称SQA)要有很强的沟通能力。从实施SQA的目的中可以看出,SQA不在项目中,是独立于软件项目的第三方,但他要了解项目的开发过程和进度,捕捉到项目中不符合要求的问题,这就要求SQA能够深入项目,和软件开发经理以及项目组中的开发人员保持很好的沟通,这样才能及时获得真实的项目情况。

2. SQA要熟悉软件开发过程。作为SQA,既然要确保项目组制定的计划、标准和规程,要符合项目组要求,那么SQA首先自己就要了解软件项目开发过程,以及企业内部已经有的开发过程规范。

3. SQA本身要有很强的计划性。SQA一方面要监督软件项目组编写计划,另一方面SQA自身的工作也要有计划,并且能够按照计划开展工作。

4. SQA要能应对繁杂的工作。作为SQA,在跟踪项目进行过程的时候要对项目组的很多工作产品进行审计,而且会参与项目组中的多种活动。同时一个SQA还有可能会面对多个项目组,所以任务相对繁杂细碎,这就要求SQA在处理这些事物的时候要耐心细致。

5. SQA要客观,有责任心。作为第三方对项目过程进行监督,SQA要能保持自己的客观性,不能一味讨好项目经理,也不能成为项目组中的宪兵,否则会影响工作的开展。对于项目组中多次协调解决不了的问题,能够向项目的高层经理进言,完成SQA的使命。

以上五点是作为SQA应该具备的基本素质,除此之外,一个好的SQA还应该在软件开发过程中作为开发人员或测试人员参与过一个或多个环节,这样他们才能在过程监督中比较准确地抓住重点,同时他们的意见和提出的解决办法也会更贴近项目组,容易被项目组接受。

SQA人员的组成

软件企业中的SQA人员既可以由全职人员担任,也可以由企业内具有相关素质、经过SQA培训的人员兼职担任。由此组成的SQA小组可能是一个真正的物理上存在的独立部门,也可以是一个逻辑上存在的平台。但不管是真正的独立部门还是逻辑上的平台,它都需要有一个灵魂人物——SQA小组组长,来组织SQA小组的日常活动。

在给一个项目组分配负责监督其项目过程的SQA时,一定要注意一点:就是该项目的SQA不能是该项目组的开发人员、配置管理人员或测试人员,一个项目的SQA除了监控项目过程,完成SQA相关工作以外,不应该参与项目组的其他实质性工作,否则他会与项目组捆绑在一起,很难保持客观性。

SQA工作的内容

SQA的工作内容主要包括以下六类:

1. 与SQA计划直接相关的工作:SQA在项目早期要根据项目计划制定与其对应的SQA计划,定义出各阶段的检查重点,标识出检查、审计的工作产品对象,以及在每个阶段SQA的输出产品。定义越详细,对于SQA今后的工作的指导性就会越强,同时也便于软件项目经理和SQA组长对其工作的监督。编写完SQA计划后要组织SQA计划的评审,并形成评审报告,把通过评审的SQA计划发送给软件项目经理、项目开发人员和所有相关人员。

2. 参与项目的阶段性评审和审计:在SQA计划中通常已经根据项目计划定义了与项目阶段相应的阶段检查,包括参加项目在本阶段的评审和对其阶段产品的审计。对于阶段产品的审计通常是检查其阶段产品是否按计划按规程输出并内容完整,这里的规程包括企业内部统一的规程也包括项目组内自己定义的规程。但是SQA对于阶段产品内容的正确性一般不负责任检查,对于内容的正确性通常交由项目中的评审来完成。SQA参与评审是从保证评审过程有效性方面入手,如参与评审的人是否具备一定资格、是否规定的人员都参见了评审、评审中对被评审的对象的每个部分都进行了评审、并给出了明确的结论等等。

3. 对项目日常活动与规程的符合性进行检查: 这部分的工作内容是SQA的日常工作内容。由于SQA独立于项目组,如果只是参与阶段性的检查和审计很难及时反映项目组的工作过程,所以SQA也要在两个阶段点之间设置若干小的跟踪点,来监督项目的进行情况,以便能及时反映出项目组中存在的问题,并对其进行追踪。如果只在阶段点进行检查和审计,即便发现了问题也难免过于滞后,不符合尽早发现问题、把问题控制在最小的范围之内的整体目标。

4. 对配置管理工作的检查和审计:SQA要对项目过程中的配置管理工作是否按照项目最初制定的配置管理计划进行监督,包括配置管理人员是否定期进行该方面的工作、是否所有人得到的都是开发过程产品的有效版本。这里的过程产品包括项目过程中产生的代码和文档。

5. 跟踪问题的解决情况: 对于评审中发现的问题和项目日常工作中发现的问题,SQA要进行跟踪,直至解决。对于在项目组内可以解决的问题就在项目组内部解决,对于在项目组内部无法解决的问题,或是在项目组中跟催多次也没有得到解决的问题,可以利用其独立汇报的渠道报告给高层经理。

6. 收集新方法,提供过程改进的依据:此类工作很难具体定义在SQA的计划当中,但是SQA有机会直接接触很多项目组,对于项目组在开发管理过程中的优点和缺点都能准确的获得第一手资料。他们有机会了解项目组中管理好的地方是如何做的,采用了什么有效的方法,在SQA小组的活动中与其他SQA共享。这样这些好的实施实例就可以被传播到更多的项目组中。对于企业内过程规范定义的不准确或是不方便的地方,软件项目组也可以通过SQA小组反映到软件工程过程小组,便于下一步对规程进行修改和完善。

SQA与几类角色间的关系

一个企业内的部门设置可能会各有不同,但是很多角色设置是相同的,从一个项目的SQA出发,我们可以把SQA与其他相关角色的关系表示为下图: 以上图示只说明SQA与高层经理、项目组和其他相关组之间的关系,并不是以上几个角色之间所有关系的描述,所以即便项目组会直接向高层经理汇报,但与 SQA无直接关系,在图中就没有表现出来。

SQA工作中常见的几个问题

1. 最初给项目组配置SQA人员的时候,SQA的价值不被认可因为是新工作的初次开展,已经习惯了自己管理项目,向高层经理汇报的项目组难免会有抵触情绪。要从两个方面解决这个问题:一方面,从组织的角度,要明确SQA的角色及其合法性; 另一方面,SQA也要以其专业的工作赢得项目组认可,为项目组增加价值。

2. 一个全职的SQA可以同时兼任多少个项目的SQA工作对于不同的项目规模和组织管理方式,这个问题会有不同的答案,根据实施中的一些经验总结,通常在第一次实施时,承担一个20人左右的项目组的SQA工作需要占用一个人30%左右的工作量,随着SQA的成熟,这个比例会降低到15%。对于一个10人以内的项目组,SQA需要投入其10%左右的工作量。当然,项目越大SQA的投入就越多。

3. SQA与项目组的关系难处理对于SQA与项目组的关系,应该遵循以下两条原则: 要在过程方面成为项目组的严师,有错必纠,但不能有错全报;要做项目组的朋友,但不能对项目组包庇纵容。

4. 项目组有了SQA,可是需求文档和设计文档的质量还是不高对不起,这不是SQA的直接工作范围。提高需求和设计的质量,要从人员培训和严格评审入手,让有经验有资格的人来完成需求和设计文档。SQA只能从规程符合方面进行监督。

总之,在软件企业中建立SQA体系,是软件项目管理由人治到法治的一个必经阶段,也是软件企业以CMM模型为参考,进行软件过程改进中一个不可缺少的部分。软件企业只要真正建立了SQA规范,培养了专业的SQA人员就会真正从中体会到它的好处。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1 主题内容与适用范围 本规范规定了在制订软件质量保证计划时应该遵循的统一的基本要求。 本规范适用于软件特别是重要软件质量保证计划的制订工作。对于非重要软件或已经开发好的软件,可以采用本规范规定的要求的子集。 2 引用标准 GB/T 11457 软件工程术语 GB 8566 计算机软件开发规范 GB 8567 计算机软件产品开发文件编制指南 GB/T 12505 计算机软件配置管理计划规范 3 术语 下面给出本规范中用到的一些术语的定义,其他术语的定义按GB/T 11457。 3.1 项目委托单位 project entrust organization 项目委托单位是指为产品开发提供资金并通常也是(但有时也未必)确定产品需求的单位或个人。 3.2 项目承办单位 project undertaking organization 项目承办单位是指为项目委托单位开发、购置或选用软件产品的单位或个人。 3.3 软件开发单位 software development organization 软件开发单位是指直接或间接受项目委托单位委托而直接负责开发软件的单位或个人。 3.4 用户 user 用户是指实际使用软件来完成某项计算、控制或数据处理等任务的单位或个人。 3.5 软件 software 软件是指计算机程序及其有关的数据和文档,也包括固化了的程序。 3.6 重要软件 critical software 重要软件是指它的故障会影响到人身安全会导致重大经济损失或社会损失的软件。 3.7 软件生存周期 software life cycle 软件生存周期是指从系统设计对计算机软件系统提出应用需求开始,经过开发,产生一个满足需求的计算机软件系统,然后投入运行,直至该软件系统退役为止。其间经历系统分析与软件定义、软件开发以及系统的运行与维护第三个阶段。其中软件开发阶段一般又划分成需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试以及安装与验收等六个阶段。 3.8 验证 verification 验证是指确定软件开发周期中的一个给定阶段的产品是否达到上一阶段确立的需求的过程。 3.9 确认 validation 确认是指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。 3.10 测试 testing 测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。 3.11 软件质量 software quality 软件质量是指软件产品中能满足给定需求的各种特性的总和。这些特性称做质量特性,它包括功能度、可靠性、易使用性、时间经济性、资源经济性、可维护性和可移植性等。 3.12 质量保证 quality assurance 质量保证是指为使软件产品符合规定需求所进行的一系列有计划的必要工作。 4 软件质量保证计划编制大纲 项目承办单位(或软件开发单位)中负责软件质量保证的机构或个人,必须制订一个包括以下各章内容的软件质量保证计划(以下简称计划)。各章应以所给出的顺序排列;如果某章中没有相应的内容,则在该章标题之后必须注明“本章无内容”的字样,并附上相应的理由;如果需要,可以在后面增加章条;如果某些材料已经出现在其他文档中,则在该计划中应引用那些文档。计划的封面必须标明计划名和该计划所属的项目名,并必须由项目委托单位和项目承办单位(或软件开发单位)的代表共同签字、批准。计划的目次是: 引言 管理 文档 标准、条例和约定 评审和检查 软件配置管理 工具、技术和方法 媒体控制 对供货单位的控制 记录的收集、维护和保存 下面给出软件质量保证计划的各个章条必须具有的内容。 4.1 引言 4.1.1 目的 本条必须指出特定的软件质量保证计划的具体目的。还必须指出该计划所针对的软件项目(及其所属的各个子项目)的名称和用途。 4.1.2 定义和缩写词 本条应该列出计划正文中需要解释的而在GB/T 11457中尚未包含的术语的定义,必要时,还要给出这些定义的英文单词及其缩写词。 4.1.3 参考资料 本条必须列出计划正文中所引用资料的名称、代号、编号、出版机构和出版年月。 4.2 管理 必须描述负责软件质量保证的机构,任务及其有关的职责。 4.2.1 机构 本条必须描述与软件质量保证有关的机构的组成。还必须清楚地描述来自项目委托单位、项目承办单位、软件开发单位或用户中负责软件质量保证的各个成员在机构中的西相互关系。 4.2.2 任务 本条必须描述计划所涉及的软件生存周期中有关阶段的任务,特别要把重点放在描述这些阶段所应进行的软件质量保证活动上。 4.2.3 职责 本条必

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值